LFS Future Braindump
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
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
More information about the blfs-dev