[Re: [Re: Building without chroot'ing]]

Richard Lightman 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
> them?
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
> >hassle.
> 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
       configuartion options.
     + 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
       new installation.
     + 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
  unpriviledged user.
* 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 mailing list