LFS Future Braindump

Gerard Beekmans gerard at linuxfromscratch.org
Mon May 26 07:36:09 PDT 2008

I'm cross-posting it as various bits have discussed on both lists and 
what is said here does apply to both books.

> Looked back at the 5.0 version of BLFS to see these Courier 
> instructions.  That is exactly the sort of thing I had in mind, but I 
> can see how it could become a maintenance burden, considering version 
> upgrades and the variability of installed optional dependencies.
> I think that, if we did go with the course modules idea, it would be 
> reasonable to limit testing to a smaller number of possible 
> combinations, say 1-3 of the more common cases.  This would be made 
> explicit on the page, and alternate scenarios could be put on the wiki.  
> I think limiting test cases will become more of a help if/when package 
> management and multiple architectures are introduced in LFS.
> For now, I think I would agree with DJ's take that this kind of 
> information is best suited for the wiki.  If I can get a working 

If the following was brought up already, my apologies.

Rather than putting everything into the book ourselves and then having 
to subsequently maintain it through version updates, we can indeed point 
to our wiki pages are mentioned above.

There exists numerous docs online that explain these topics in great 
length because they are dedicated to it, rather than us trying to cover 
a lot of territory. If we can't add it to the books and we don't have a 
wiki page for it, why not collect such links and provide them as 
alternate reading sources just before/after the package's installation 

I know, that means frequently having to check for dead links but that 
may be less time over all than re-writing and testing our own instructions.

These combinations (in books, wiki, external pages) may just work to put 
together a comprehensive resource on the topics that need the extra 


More information about the lfs-dev mailing list