LFS Future Braindump

Alexander E. Patrakov patrakov at gmail.com
Sun May 25 08:34:52 PDT 2008

(sorry for the overall pessimistic tone)
Robert Daniels wrote:

> My first point is one that has brought up before.  We need better 
> descriptions of the packages and why you might want them. We all do a
> wonderful job of documenting build dependencies, instructions, and
> methodologies, but less so on why we are building things.

So, in other words, you want concrete example use cases to be documented in 
BLFS. Good idea.

> Second, I find that there is an almost total lack of information on how 
> to make the various pieces work together.

I think this happens because many packages are added just as (possibly optional) 
dependencies of something else. For such cases, it is easy to fall into the trap 
of presenting the minimal instructions sufficient only for a package being found 
by its reverse dependencies. Probably, this can be solved by adding the 
mandatory "examples" section to each package (even library packages, where some 
reverse dependency of the library is called, e.g., for libIDN, show how to get 
the contents of http://räksmörgås.josefsson.org/ using cURL).

OTOH, some time ago we had a fully written Courier MTA setup example (by Jim 
Gifford), that was removed (presumably because nobody was interested). I think 
that, before we start implementing Alan's "course modules" suggestion, we should 
first find out what went wrong in the Courier case, in order to avoid repeating 
mistakes that led to this situation.

P.S. ums.usu.ru still uses Courier MTA (although in a simpler setup, without 
virtual users or a database).

Alexander E. Patrakov

More information about the blfs-dev mailing list