Actual tool design

Eric A. Ayer mwalker at
Mon Jun 26 21:41:34 PDT 2000

<snip lots o' text>

This is essentially what I've been thinking of too.  The install tool could
run shell scripts in one of several available modes, like run straight
through, step-by-step with confirmation of each step and possible editing, or
maybe a mode where it stops at breakpoints.

On top of that, sets of packages/scripts could be grouped together.  You could
run all the 'basic system' scripts to get a working system, and then run the
'inetd progs' script to get all of the inetd utils installed.  Maybe other
groups could take care of X and window managers.

I've been thinking about some of the programs, like perl, which have these
long ./Configure -ation sequences.  The config for perl can be saved, so maybe
a package allows for different preset configurations or allows the user to
actually run ./Configure and answere the questions.

I think that the 'framework' concept is what we're aiming at.  It's all going
to come down to running shell commands in the end, such as 'make' and 'make
install'.  I don't have an idea on how to implement a program or tool that
does this, but something will filter out soon I hope.


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