ALFS Direction Revisited
jwrober at linuxfromscratch.org
Tue Nov 16 15:10:13 PST 2004
Matthew Burgess wrote:
> Jeremy Huntwork wrote:
>> 1) We need to rebuild our mission statement or create one. Currently,
>> the best thing I found is here:
>> Interestingly, that page mentions part of the purpose of ALFS is
>> automated system administration, which I've never seen happen with our
>> current tool.
> OK, this is purely MHO. I really don't think that ALFS should have
> anything to do with system administration. LFS provides instructions
> for *building* the book. Administration is left up to the user, and
> quite rightly too. ALFS, by definition then, should automate what LFS
> teaches, ergo be a tool for automating *builds*. Of course, as someone
> who has his own home-grown build scripts that he's unwillingly trying to
> orphan, I'd like some of their functionality in ALFS too if possible.
> 1. Log all output that I'd see on the screen
> 2. Log all newly installed files
> 3. Log build times, both in SBUs and in "wall time"
> 4. Log maximum diskspace requirements during the build process
> OK, so my scripts don't do number 4 (yet), but the first 3 are
> relatively trivial to implement. I think number 1 easily fits in to the
> requirements of an automated build tool - if the build goes wrong you
> need to be able to track where it went wrong. Number 2 can be argued
> for in a similar manner - the build might fail because a previous
> package didn't install a file that we expected later on.
> Number 3 is purely there for LFS reasons, and could probably be catered
> for via an LFS-specific hack^H^H^H^Hextension. Number 4 is again for
> LFS reasons, and I'm not sure if it'll provide any value to ALFS or its
> general userbase.
Good points all Matt. I think what were getting at in the old mission
statement was that ALFS provides a framework for whatever you want it to
do. It can (future) build a box with all 4 of your requirements (all
good btw), but with custom profiles can be used to do all sorts of
stuff. Some of us are looking for package manager type functions as
well which goes into the realm of systems administration. This is the
same thing that shell scripting provides in some cases. The logging DTD
is going to be a huge step in the right direction IMO. Using nALFS to
do builds and/or sys admin work with all the logging will really come in
handy. Actually, something I want to see in nALFS2 is a log
parser/analyzer feature to rip the log apart in the gui.
More information about the alfs-discuss