ALFS Direction Revisited
matthew at linuxfromscratch.org
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
More information about the alfs-discuss