Actual tool design

Simon Perreault nomis80 at
Tue Jun 27 13:44:43 PDT 2000

> <snip>
> > 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.
> > 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
> > 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
> > 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
> > to the LFS standards and is bug-free.
> >
> > I envision the tool as being highly module-oriented (the profiles). It
> > keep track of which profiles are currently installed. If you go further
> > coding, it could keep track of which files were installed with which
> > package.
> Interesting idea, kind of like rpm's, but easier to configure and install
> complicated setups.  And if the scripts are written clearly enough, using
> updated version of the source it was meant for wouldn't be too much

Advantages over rpms:
1) You get to compile the source yourself. You don't install pre-compiled
binaries, so you may enable optimization.
2) You don't have to download a big tarball enabled for the tool. You just
download the script if you want to use the tool with the tarball.

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