LFS and BLFS
Alexander E. Patrakov
patrakov at gmail.com
Sat Dec 15 00:26:19 PST 2007
2007/12/15, Bruce Dubbs <bruce.dubbs at gmail.com>:
> The major thing that makes LFS a bit easier to maintain is the fact that
> there are only about 50 packages in LFS vs about 300 in BLFS.
Not only that. LFS has no options, and BLFS has a lot of them. E.g.,
on (now commented out) Xfce page, one can start the build with or
without HAL and policy-kit. Thus, strictly speaking, an editor has to
test both possibilities and provide instructions for both of them
(i.e., show how to mount removable volumes with the correct options
and how to shut down the system - I did this only in one case, because
for me HAL integration is broken beyond repair when mounting removable
media and because policy-kit is not in the book). That's a lot more
work than in LFS. Adding a section about the configurations (i.e.:
actually used dependencies and actually passed ./configure switches)
tested by BLFS editors and known bugs in them would help.
> Rolling a
> new .x version if LFS is relatively easy. Its only when we do something
> major like we are considering with x86_64 or adding DESTDIR rules when
> it becomes compilcated. Since it is the base of the entire system, LFS
> needs to be very solid. Packages in BLFS are somewhat more independent.
There is still one large-scale change on the horizon: conversion of
manual pages to UTF-8 when LFS switches to groff-2.0 and the
corresponding version of man-like program. But this is expected in
year 2010 or so.
> I don't really like this idea. I do not build every package in BLFS and
> I would think very few do. What is nice is when I do want a package, I
> have one place to go. There I can look at the dependencies, which may
> be from several places, and build. I wouldn't like the idea of having
> to look at multiple books to do this. The idea behind BLFS was to give
> people choice.
While I agree with this, it conflicts with the book being well-tested.
See above for the proposal about a new section on each page.
> > "Adopt a package and be the maintainer."
> That is an interesting idea. At one time I wanted to assign certain
> areas to individual editors, but that idea was not liked by the other
> editors. It would take some oversight to ensure a consistent quality level.
IMHO, it would be useful to mark unmaintained packages, too.
Alexander E. Patrakov
More information about the blfs-dev