summaryrefslogtreecommitdiff
path: root/manpages
diff options
context:
space:
mode:
authorLyndon Brown <jnqnfe@gmail.com>2020-04-06 16:49:08 +0100
committerRaphaël Hertzog <hertzog@debian.org>2020-04-23 16:54:31 +0000
commitc441c39efe636a76e496f0e5c36401b6b0750496 (patch)
tree5f2ee55fcc35180a210920a0aa6131403595cdce /manpages
parentbf63762721ddfa497e1b6e4b311178fd68a0b012 (diff)
downloadvyos-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.14
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.