Notes on handling of defaults
How are defaults beeing handled in live-helper?
-----------------------------------------------
Each and every helper processes Set_defaults(); from
functions/defaults.sh. Set_defaults(); follows two basic priciples:
* If a variable is unset, it is automatically set to a (sane) default.
* If a variable is not empty, it is left as-is.
Therefore, it is ensured, that if Set_defaults(); is called initially by
lh_config, each and every variable is not left empty in the config that
is written to the disk.
The hierarchy of methods in order to manipulates values of variables is
the following (earlier methods are overwritten by later ones):
* environment varialbles, if existing (though this should never be
done anyway)
* contents of /etc/default/live-helper, if existing [0].
* contents of $(pwd)/config/*, if existing.
* command line arguments, if existing (also see [1]).
* local configuration file (passed through -c|-conffile FILE, but also
see [2]).
* Set_defaults(); (works as explained above).
Apart from the normal case where a variable just contains an arbitrary
string, there are the following special variables:
* Some which contain by default a 'regular' value, but which are
manually expanded at runtime. Example: LH_INITRAMFS.
* Some which contain by default a variable, which is automatically
expanded at runtime. Example: LH_UNION_FILESYSTEM in
LH_LINUX_PACKAGES, VERSION in LH_ISO_PREPARER.
* Some which contain by default a command, which is automatically
evaluated at runtime. Example: date call in LH_ISO_VOLUME.
Why it is like it is
--------------------
For the normal case where variables just contains arbitrary strings, I'd
say everything works perfectly for everyone.
In the case of special variables, an additional parsing run is required.
This enforces that everyone is calling 'lh_config && lh_build' and not
'lh_build' only, but has the advantage that those can be kept automatic.
Why keeping them automatic? Because some values are *conditional*.
Imagine the case where you want to build both etch images and lenny
images from the very same live-helper configuration. Without automatic
variables, you would need to first set LH_INITRAMFS to casper, build the
etch images, then change it to live-initramfs and build the lenny version.
By having LH_INITRAMFS set to auto, Set_defaults(); automatically sets
it to the correct value depending on the distribution you are building.
Or in other words: It is enough to change the distribution, and the
*default* values of the other variables that are a requirement in order
to build a normal image out of the debian.org repositories
*automatically* behave the right way in order to not make live-helper fail.
The same applies for LH_UNION_FILESYSTEM. If you decide to use unionfs
rather than aufs (let's assume that there would be working unionfs
packages in the archive), why should live-helper be so dumb and insist
on installing aufs-modules-2.6-$foo *against* the user who wanted to
have unionfs (remeber, we're not speaking about people that are
enforcing certain variables to concrete values - but about defaults).
One can argue that this sucks, but this is a really good thing for
people that are not following debian-live closely enough to know such
subtile differences, and also for us so that we don't have to teach
people to remember to adjust their configs all the time. And, it adds a
bit of comfort, after all.
And, these benefits clearly outweights the requirement of needing people
to be forced to call lh_config once initially.
Bugs in defaults handling
-------------------------
Now, if you find any flaw in the *implementation* of above (and I'm sure
everything can always be improved), you're welcome to point fingers and
cluebat me.
If you find the above *design* to be flawed, feel free to cluebat me as
well - but make sure you come up with another one, that supports the
same features towards the users.
Also, things like the (hypothetical) following stuff are non-arguments:
"I'm using live-helper in an unsupported way (by not calling
lh_config), I don't want to call lh_config and use my own tool, but
don't want to live with the consequences and want you to change
everything because I'm doing this in this unsupported way since a
long time and you broke it with the introduction of automatic
values."
Also, (hypothetical) statements like "this is broken" or "doesn't work
for me" doesn't help at all - give a *precise* use case with all the
involved commands that are step by step reproducible, and a *precise*
reason why you want to have something changed. if possible, accompany it
with a patch to illustrate it.
And yes, this is specifically targeted at #490290 and #500740. Even in
this cases, please follow up with a suggestion described in the previous
paraphraph - e.g. we vasted a *really* *lot* of time there just because
the two submittors refused to reveal right at the beginning that they
are *not* calling lh_config initially.
Regards,
Daniel
[0] afaik only lh_config does this - probably all helpers should do that
individually.
[1] not all helper are currently overwriting stuff from the
configuration files with command line arguments - this is a bug and
should be fixed, but the hierarchy given here is how it should be.
[2] not all helper are currently supporting this properly - this is a
bug and should be fixed.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
Reply to: