[Re: [Re: Building without chroot'ing]]
richard at nezumi.plus.com
Thu Jan 2 02:23:33 PST 2003
* Eric Miller <emiller at techskills.com> [2003-01-02 07:06]:
> This is just what I was looking for, thanks Richard. As I go through these,
> do you mind if I bounce my "proposed" install commands to you before running
You can send them, but I will probably answer "what results did you
> >I install everything via DESTDIR, and it has taken a lot of time to
> >find out how. As you were looking at cutting the install time by
> >missing a few things out, I thought you would prefer to avoid the
> Actually, its not so much of a cutting install time thing. Its more of a I
> don't want to chroot thing. I have (a very clunky) install script that I a
> re-writing, and I want to minimize user interaction. Chroot is one thing that
> requires user interaction, unless I can cause chroot to automatically "pick
> up" where the script "left off", then I want to skip chrooting. Actually,
> that is another question all together:
My alternative automated lfs make files (ralfs) already do that. Here
is the blurb:
* Customization: Build instructions for each package are made up of
auto detecting defaults that can be overridden for individual
packages, and groups of packages.
+ The source for each package is found anywhere in the specified
directory trees using regexes. You can override the regex to get
a specific version. You can replace the source code with a new
version, and ralfs will find it.
+ If you do not prevent it, ralfs will look for and apply a patch
with a name that matches the name and version of the source.
+ You can specify a list of extra patches for ralfs to find and
+ By default the environment variables LFS, PATH, and TERM are set
to sensible values (that you can override). You can add other
variables to the environment such as CFLAGS for individual
packages, groups of packages, or globally.
+ If there is a configure script, ralfs will run it (unless you do
not want it to). You can add to, modify or replace the
+ If there is a make file, ralfs will use it. You can add to,
modify or replace make options.
+ If I spotted a self test suite, ralfs will run it, and log the
results. (Yet again, you get to play with how this is done.)
+ The install stage is configurable in the same way as the make
+ There are hooks for adding extra commands before and after the
unpack, patch, make, test and install stages.
* Ease of adding new packages. Ralfs needs to know what a new package
depends on, but can figure out standard autoconf packages, and simple
make && make install packages. There is a fair chance that all you
have to add is any unusual configure options.
* Ralfs does not get completely stuck if something does not work. It
will continue with other packages (subject to dependancies).
* Ralfs automates some of the tasks required to use a new operating
+ Ralfs can collect your configuration files, and put them in the
+ Ralfs can copy selected user/group id's and passwords from the
host to the new installation. (This is handy if you share for
example /home between two or more installations.)
* Security: All the stages from unpack to install are carried out as an
* All packages are installed using DESTDIR. This makes it easy for
ralfs to keep track of which files comes from each package, and to
correct some annoying issues without symlinks (like /usr/man).
* Ralfs creates filesystems on the required partitions.
* Ralfs umounts/mounts the required partitions.
* Ralfs can be stopped, and later, told to continue from where it left
* Ralfs can compile multiple packages simultaneously.
* If you have patched make to use the customs library, ralfs might do
something useful with a cluster.
* Ralfs keeps track of which packages are installed, any patches that
were applied to them, which ones failed, and how long each one took.
* Build data for a package can be modified even while ralfs is running.
* Ralfs defaults are as close as is practical to LFS-BOOK so you have a
reasonable idea of what will be built.
* Ralfs makes trace files for each package for debugging. I have put
some effort into make the trace files readable.
* Failed packages can be retried from where they failed, or you can
start again at these stages: unpack source, patch, configure make,
test or install.
* (Experimental) support for cross compiling.
Current problems with it:
1) The documentation is incomplete.
2) I broke it when making changes forthe latest gnome, X, and glibc,
and have not fixed them yet or tried their dependancies recently.
3) At present, some commands have to be protected against expansion by
make and a shell to work. New features in make version 3.80 allow
this to be made unneccessay, and I wanted to make those changes
before letting the files out into the real world.
If you are interested, I will send you the developement version.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message
More information about the lfs-support