Actual tool design

Simon Perreault nomis80 at
Mon Jun 26 19:34:26 PDT 2000

> The first question that comes to my mind is how much information should
> that profile contain. Take the "creating directories" subsection of the
> LFS book. Do you put even such basic information in a profile (so that
> it can be overridden) or do we put such basic information in the tool
> itself and have a profile override it.

I was in my shower, and I just had a very shining idea (well, I guess it's

First of all, I see this tool as a way to install packages on a system,
according to the LFS standards. Nothing more.

Second, I see profiles as being the information that the tool needs to
install the package. What commands need to be run, etc. Nothing more. (You
could include header-like files for default options, like the directory
creation step you talked about.)

So I just realized something: after LFS is installed, the tool could still
be used to install packages according to the LFS standards (the init
scripts, for example). You must realize that you have a lot of volunteer
workforce here. Linux community is about giving it as much as you receive
from it. Let's say that we could write our own "profiles" for optional
packages, and send it to Gerard, which puts it on the website if it conforms
to the LFS standards and is bug-free.

I imagine a section on where there would be a table
made out of two columns: one to list the profiles available for download,
and another one to list the tarballs that need to be downloaded to be able
to install the profile.

ie. Let's say I want to install a dhcp client on my machine, after having
installed one of the general LFS-install profiles. I go to the section on, I check dhcp, I find a profile to install a program
named dhcpcd. I download the profile and the tarball, I run the profile
using the tool, and bang, my machine is connected to the dhcp server.

I envision the tool as being highly module-oriented (the profiles). It could
keep track of which profiles are currently installed. If you go further into
coding, it could keep track of which files were installed with which

Have the profiles be as easy to write as shell scripts and you will soon
have a huge database of profiles to install every single package according
to LFS standards.

As usual, this is only my newbie advice. (I'm dreaming of the day when I'll
be coding important kernel parts and signing my work with this exact same

Simon Perreault

Mail archive:
IRC access: server: port: 6667 channel: #LFS
Unsubscribe: email alfs-discuss-request at and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the alfs-discuss mailing list