Actual tool design

L Vogtmann vogtmann at
Tue Jun 27 11:36:16 PDT 2000

Hash: SHA1

> 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 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
> 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 an
updated version of the source it was meant for wouldn't be too much trouble.
Vmann <vogtmann at>
PGPkey <>
Licq #14259386

Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see

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