a suggestion for the CLFS book

Matt Darcy lfs-list at projecthugo.co.uk
Tue Nov 1 14:18:48 PST 2005

Hello Robert,

Thanks very much for your suggestion with regard to the cross-lfs book and possible improvments
While your suggestion makes for useful reading for a student / teacher style book, the overhead and usefulness of this feature within an LFS book, from experience actually turns counter productive.
This is more so in cross-lfs than probably any of the other books.

To use a simple example,

In the LFS book, there is a comment showing how to check the results of the test suite for glibc.
These results will be pretty much the same for every user, with a few exceptions. The pain this one test suite validation causes with regard to developing and supporting the project, far out does its usefullness, to the point I'd rarther it wasn't actually there.
If you then imagine doing this for every step on an LFS build, not just one components test suite, it would be impossible to maintain, now consider multiple hosts and multiple targets, and multiple build configs in cross-lfs and you'll see that this is impossible.

There should be a level of self validation available to any user, which is just common sense, in that as long as your "make" doesn't give you any fatal errors, your generally "ok"
or if you get warnings, closer manual inspection of the warnings and the components related to the warnings should give you a better idea to possible failures. 
Also manual inspections of the test suites as a guide would be a good idea.

If your uncomfortable with any of this, you can always ask the lfs support processes to validate anything your really concerned about, and as long as you've used common sense you'll get a good response.

thanks for the input, but hopefully you'll see why its just not a useable option.


  one of the things that i think would be useful in the midst of therecipe to build a CLFS is to, after each page of instructions, explain
what should have happened and what changes/additions in terms of files
or directories the user should expect to see.

  this acts as a kind of validation so that the user can verify that
what he just did produced the correct results.  i've used this
approach in a lot of the docs i've written and it's always been pretty
popular with my students.


More information about the cross-lfs mailing list