diff options
author | Lyndon Brown <jnqnfe@gmail.com> | 2020-04-06 16:49:08 +0100 |
---|---|---|
committer | Raphaël Hertzog <hertzog@debian.org> | 2020-04-23 16:54:31 +0000 |
commit | c441c39efe636a76e496f0e5c36401b6b0750496 (patch) | |
tree | 5f2ee55fcc35180a210920a0aa6131403595cdce /manpages | |
parent | bf63762721ddfa497e1b6e4b311178fd68a0b012 (diff) | |
download | vyos-live-build-c441c39efe636a76e496f0e5c36401b6b0750496.tar.gz vyos-live-build-c441c39efe636a76e496f0e5c36401b6b0750496.zip |
config: revert partial format conversion
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 44b9b0a6501476de594ce3783cea5df0c141478c, 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
Diffstat (limited to 'manpages')
-rw-r--r-- | manpages/en/lb_config.1 | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/manpages/en/lb_config.1 b/manpages/en/lb_config.1 index 5975a49df..9f7adbb7e 100644 --- a/manpages/en/lb_config.1 +++ b/manpages/en/lb_config.1 @@ -1,4 +1,4 @@ -.TH LIVE\-BUILD 1 2020\-03\-30 1:20191222 "Debian Live Project" +.TH LIVE\-BUILD 1 2020\-04\-06 1:20191222 "Debian Live Project" .SH NAME \fBlb_config\fR \- Create config directory @@ -225,7 +225,7 @@ .PP \fBlb config\fR populates the configuration directory for live\-build. This directory is named 'config' and is created in the current directory where \fBlb config\fR was executed. .PP -Note: \fBlb config\fR tries to be smart and sets defaults for some options depending upon the settings of others. However, this only typically happens when no existing saved config exists, because values are only automatically set when not already defined (and running \fBlb config\fR involves loading any existing config). This means that when generating a new configuration, you should typically first ensure that any existing saved config files are removed (by deletion of \fBconfig/{binary,build,bootstrap,chroot,common,source}\fR), before then calling \fBlb config\fR just once with \fBall\fR necessary options specified. Calling it when an existing saved config exists risks ending up with a non\-working configuration, depending on the options changed, since in doing so other options may end up with different values than they otherwise might have had had automatic setting of them not been blocked by an existing saved value. In some cases invalid combinations will be noticed and reported as an error or warning, but this is not always the case and should not be relied upon. +Note: \fBlb config\fR tries to be smart and sets defaults for some options depending upon the settings of others. However, this only typically happens when no existing saved config exists, because values are only automatically set when not already defined (and running \fBlb config\fR involves loading any existing config). This means that when generating a new configuration, you should typically first ensure that any existing saved config files are removed (by deletion of \fBconfig/{binary,bootstrap,chroot,common,source}\fR), before then calling \fBlb config\fR just once with \fBall\fR necessary options specified. Calling it when an existing saved config exists risks ending up with a non\-working configuration, depending on the options changed, since in doing so other options may end up with different values than they otherwise might have had had automatic setting of them not been blocked by an existing saved value. In some cases invalid combinations will be noticed and reported as an error or warning, but this is not always the case and should not be relied upon. .SH OPTIONS In addition to its specific options \fBlb config\fR understands all generic live\-build options. See \fIlive\-build\fR(7) for a complete list of all generic live\-build options. |