LFS Future Braindump

Robert Daniels rdaniels at linuxfromscratch.org
Mon May 26 06:23:27 PDT 2008


On Sunday 25 May 2008 10:34:52 Alexander E. Patrakov wrote:
> (sorry for the overall pessimistic tone)
>
Not a problem.  If my ideas are unworkable, I need to be told.  As long 
an offensive tone isn't taken (which it wasn't), I'm OK.

> 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.
>
This point was referring to the package description placed at the top of 
each page.  There are some packages where you would not know if you 
needed it unless you already had a fair amount of knowledge in that 
area, like OpenLDAP, xinetd, libksba, probably some others.  I'm not 
saying we should go on for pages and pages with descriptions, but at 
least enough so the descriptions are useful.  What is this Lightweight 
Directory Access Protocol that OpenLDAP implements?  What is this inetd 
that xinetd is replacing?  Libksba isn't quite so bad, at least you 
understand it has something to do with cryptography.

> > 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. 

I don't think it's necessary (or even desirable) to add a use-case for 
every package in the book.  In particular, most libraries would not 
benefit from this.  Also, many desktop applications like media players 
or image viewers are quite obvious in how they are meant to be used.

> 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.
>

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 
LDAP/Kerberos configuration figured out, I'll add it.  After running it 
by Randy, if he's willing, to spot any big security problems, as he has 
some experience with this type of setup.  He did write the hints, after 
all.

-- 
Robert Daniels



More information about the blfs-dev mailing list