ALFS Direction Revisited

Matthew Burgess matthew at
Tue Nov 16 14:50:53 PST 2004

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.



More information about the alfs-discuss mailing list