ALFS Direction Revisited

James Robertson 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:
>> http://www.linuxfromscratch.org/alfs/whatisalfs.html
>> 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.

James



More information about the alfs-discuss mailing list