How the lsbsi build works

As a point of information, I needed to write
up a new description of the lsbsi build
process to fill in some missing material
for the lsb book.  Since it might be helpful,
provide a slightly different viewpoint on
the build, or whatever, I'm reposting that
description here.


The first, or bootstrap, phase of the LSB-si build is to
produce a minimal toolchain of static binaries. The
static build is designed to get the shared libraries of
the host platform out of the equation, and to avoid having
to fiddle with dynamic linkers and so forth in trying
to run from an alternative set of paths (note that current
versions of Linux From Scratch do the fiddling quite
successfully, but for this release we should not look
at such architectural changes).

The second phase of the build is to use the bootstrap
phase as a chroot environment to build a more complete
toolchain.  As binaries are rebuilt which were built
in the bootstrap phase, the new ones install on top
of the old static copies so that by the end of the
second phase, a complete build environment is in place,
using dynamic binaries/libraries.  This environment has
the characteristic that it is entirely isolated from the
details of the build host's build enviroment, since
none of the build host's tools have been used to
compile the final binaries and libraries.  Also note the
the term "complete build environment" is qualfied, it's
the list that, through, trial-and-error and other sources,
has been determined to be necessary and sufficient to
build the lsbsi-final.

Clarifying side note: To reduce rebuild time, the bootstrap
phase is copied to another location before starting, and 
the copy is used as phase2.  During LSB-si development, 
there tend to be few changes to the bootstrap, but many 
to the later phases. For a released LSB-si source tree, 
this really doesn't matter except that it increases the 
space requirements of the build area a bit (only about 
150 meg for an ia32 build host, however).  Thus the "copy 
bootstrap to phase2 part is not an essential part of the 
build strategy, but rather a convenience for LSB-si
developers.

Phase 3 is the construction of the actual LSB-si as it
will be delivered.  In this phase, the completed phase 2
is used in a chroot as the build environment, and each
package is then compiled, and installed to a target
location which will be the LSB-si tree.  During phase 3,
care is taken not to install unnecessary binaries or
libraries, often an upstream source package will build
and install more than is required by the LSB and these
are (where it makes sense) pruned from the final tree.

Because we already anticipate several uses for the LSB-si
that require more than the core set, there exists a
phase 4 which builds add-on bundles that can be installed
on top of the base LSB-si bundle to provide additional
functionality.  There are currently three sub-phases of
phase 4, one to build additional tools required for 
running the lsb-runtime-test suite on the lsbsi, a
second to build additional binaries to make a bootable
system, and the third to build additional binaries to
make a user-mode-linux system.  Phase 4 is built by the
phase 2 build environment just like phase 3 is, and is
completely independent of phase 3.  That is, if one had
a completed phase 2, one could start off a phase 4 build
without ever building phase 3 and it would work fine.
This has implications for your diagram, which should not
show phase 4 as a sucessor to phase 3, but as a sibling
(or perhaps 3 siblings? not sure...)
It is likely there will be additional phase 4 subphases
in the future, with the one which has been requested
fairly often being a build environment.