back in v4.0~a6-1 a transition process was started to move the live-build
config to a new format. the new format was INI style, and required
parsing functions to read/write values, compared to the existing format
which was just shell script code setting variables.
this partial transition is the explanation for the existence of the
`New_configuration()` function, and understanding this is important to
understanding the purpose of it - it is not in fact intended for creating
a new configuration, it is just related to the new config format
transition.
the positives of the new format were that it was somewhat cleaner looking,
while the negative was the terrible relative efficiency.
the file `config/build` was created to hold options in this new format.
the transition was only ever completed for a handful of config options:
- architecture
- archive areas and parent archive areas
- live image name
- live image type
a 'configuration version' attribute was also saved, which is not used by
anything.
the bootstrap-mirror and parent-bootstrap-mirror attributes are pointlessly
stored in it seemingly resulting from work done in v4.0~a17-1. (they are
also stored in another config file from which the value is actually used).
it in fact seems to have been a source of confusion for Raphaël in
authoring 44b9b0a650, since the new
`[parent]-distribution-{chroot|binary}` options it introduced were stored
both in `config/bootstrap` and in `config/build`, while only used from the
former. i expect, understandably, that he thought that `config/build` was
just an information file.
Gbp-Dch: Short
the grub-pc image creation code has no business being in binary_iso, it
should be in binary_grub-pc.
it should be noted that the binary_iso script did not even have the
necessary package check for grub-mkimage, while binary_grub-pc did have
it, pointlessly.
Gbp-Dch: Short
This fixes cryptsetup modules not being installed into initrd with warning:
> cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries
> nor crypto modules. If that's on purpose, you may want to uninstall the
> 'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs
> integration and avoid this warning.
Thanks-to: Marcel Partap
live-build might be run from a local folder rather than the system
installation, so the dpkg version number should not override the version
picked up from VERSION
if we care about the possibility of the installed package version
potentially differing from the version of the git checkout, or
whatever, then this should be printed alongside it, as now done.
Gbp-Dch: Ignore
[Raphaël Hertzog: tweak to apply on top of my changes]
thus it can correctly indicate success/fail status instead of always
indicating failure. when a user asks for usage with -u|--usage then we
should exit in success mode rather than failure as when usage in printed
in response to incorrect usage.
Gbp-Dch: Short
this means that the usage goes from:
lb {-h|--help|-u|--usage|-v|--version}
lb COMMAND [OPTIONS]
to:
lb {-h|--help|-u|--usage|-v|--version}
lb [FRONTEND_OPTIONS] COMMAND [COMMAND_OPTIONS]
though it is probably not worth is to update the description in the
manpages...? hmm...
so for instance this matters for color control with --color|--no-color
(you already had full control via environment vars). previously you could
do `lb COMMAND --no-color` to turn off colour, only to find that output
at the frontend level was still coloured (the option is processed at the
command context level, not the frontend), so you might try to instead use
`lb --no-color COMMAND`, only to find that this was not supported. Well
now it is, and used at the frontend level will fully control colour output
(after the command is processed anyway).
the full set of common options are thus available (except --force) at the
frontend level, and thus for instance all Echo_*() helpers used in the
frontend will work correctly after args are processed.
furthermore usage like `lb --color --help` will actually work. (not that
color is used there, but this previously would have failed with the
frontend treating the `--color` argument as the command; that's the point!)
Gbp-Dch: Short
as far as the user is concerned, 'foo' in `lb foo` is a command; they do
not know or need to know that the commands also correspond to actual
scripts.
Gbp-Dch: Short
this was previously not done in 8b109ffb96
to keep the renaming simple, but leaving the variable plural is a cause
for confusion.
since this property is stored in the INI style config/build config file
rather than a shell script based one, at the property there is already
singular, there was no need for a backwards compatibility hack.
Gbp-Dch: Short
being done in Prepare_config() meant that it would get saved into the
config stored on disk which is not what was intended.
being saved on disk is not a big problem, since the injection of the
dynamically determined option is always done on top of the value read
from the saved config anyway, so you'd always end up with two copies of
the option given to apt, the first being from the saved config, the second
being the more correct dynamically determined one, overriding the first.
so there is no functional change here, just better achieving what was
intended.
Gbp-Dch: Ignore
note that the bit of code removed from source_debian relies upon a
variable LB_TASKS which itself is an old leftover artefact from before
v4.0.
Gbp-Dch: Short
since everywhere where 'apt' is a permitted value, 'apt-get' is also, it
just wasn't listed in the option's documentation and thus was also not
listed in the new validation check.
Gbp-Dch: Short
80aa5ab611 implemented a hack to handle
replacement of LB_LINUX_FLAVOURS with LB_LINUX_FLAVOURS_WITH_ARCH in
config files, but implemented it in the wrong place.
adding a conditional conversion within the config file meant that the old
value would only be read from **new** config files that are created
obviously without it, including re-saved configs if `lb config` were
re-run with additional options (not recommended). any existing value in an
existing config file would actually be ignored.
the right place to read the old value was in the Set_defaults() function
(since renamed).
a second issue also existed with the hack, it failed to excape the `$`
and thus printed the existing value of $LB_LINUX_FLAVOURS into the
conditional check being constructed in the config file, instead of
printing the name of the variable. the check embedded into the config
file thus became this on an amd64 machine:
```
if [ -n "amd64" ]
then
LB_LINUX_FLAVOURS_WITH_ARCH="amd64"
fi
```
which is clearly not what was intended.
Gbp-Dch: Short
while helpful for users to know the defaults, the values printed as the
supposed defaults for most are actually the same values as being
configured, or in some cases a piece of text "autodetected or empty", and
thus the information is completely wrong and actually unhelpful since it
misinforms the user.
fixing this to give the real defaults is very much non-trivial.
as a workaround users wanting to know the default for an option can always:
a. use `lb config` wit no options (or auto) in a clean directory and thus
get a config with all defaults.
b. look at the live-build code.
if they just want to reset an option, they can also just comment it out.
Gbp-Dch: Short
Closes: #904614
(and move the wget options setting down where it should be while at it)
the value of LB_DEBIAN_INSTALLER is now properly checked in the main
validation routine, so we can just directly exit here as a simple safety
check should validation be bypassed.
Gbp-Dch: Short
- add a validation check where an error will be printed
- replace the check done in the grub scripts with one that simple exits
if executed bypassing the validation check
Gbp-Dch: Short
the stuff in defaults.sh is only partially to do with setting default
config values, it also does other prep work like centralised comma
separated value to space separated conversion, and validation.
this is split into two parts to keep the diff simple, first we move the
two small functions from configuration.sh into default.sh...
Gbp-Dch: Short
move away from the somewhat config file grouping based organisation to
an alphabetised list, after grouping into script-specific; general;
build-specific and other.
the config file based organisation was a bad choice, making it hard to
find the right place to insert options for instance.
Gbp-Dch: Short
running `lb config --validate` causes the script to stop after running
the validation check on the config compiled at that point, prior to
writing the config to disk.
this gives users the ability to check the validity of a config without
modifying or rewriting the saved config.
note that if users provide new config options alongside --validate, these
are taken into account in the check performed.
the 'check complete' message will not be seen if an error is reported by
the check function, while it will be seen if only warnings are given, but
it would require a redesign of the validation check function to make any
improvement in that area, and it's perhaps not worth it.
Gbp-Dch: Short
it mostly applies defaults where a value does not exist, but does more in
some cases. the new name better reflects its usage and functionality.
Gbp-Dch: Short
Lyndon Brown
Raphaël Hertzog