LFS and BLFS
Alexander E. Patrakov
patrakov at gmail.com
Sat Dec 15 06:18:19 PST 2007
2007/12/15, Randy McMurchy <randy at linuxfromscratch.org>:
> Alexander E. Patrakov wrote:
> > 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.
> It should already be that Editors are using the book's
> instructions as a preliminary build, then adding other
> possible ./configure switches (within reason). Identifying
> bugs should also be done.
> If there is some bizarre combination the ends up with a
> weird or broken result, we can identify it if it is known.
> I think the situation with XFCE and HAL is the exception
> more than the rule.
Well, suppose that the "default mount options" bug is magically
resolved, and someone wrote a BLFS page for policy-kit. Still, there
are two drastically different configurations: with and without HAL,
that are both valid, and both have to be documented. I.e., twice the
work than for a typical binary distro that supports only one of those
> I'm still disappointed that XFCE was removed simply
> because you felt that *maybe* it will become unmaintained.
As far as I know, no other Editor uses Xfce. The LiveCD doesn't really
count, as it takes some shortcuts when building Xorg. Thus, we won't
notice when the build instructions become incorrect. Also, this page
has a large number of beyond-blfs optional links to dependencies and
On the bright side, Archaic has provided some feedback and noted some
inaccuracies in the text that was copied over from the old page. If
you verify the build size, the fact that the instructions are
sufficient to avoid HAL even if it is installed, and fix the link to
the URI perl module (it should link to an anchor on the "perl modules"
page instead of CPAN), I will fix the textual issues and uncomment the
> > IMHO, it would be useful to mark unmaintained packages, too.
> Well, I think we already sort of do. But first you would
> have to define what an "unmaintained" package is. Is it,
> 1) any package that has a newer release available but has
> not yet been updated in BLFS, or 2) any package that is
> x release versions behind, or 3) some other criteria.
IMHO, version numbers and releases are not a thing that one should
look at. Everyone is going to try the book instructions on the latest
Thus, I choose option (3): unmaintained package is a package that
doesn't have a BLFS Editor that uses it on a regular basis (i.e.: can
notice when the instructions in the book are no longer good for the
latest stable non-buggy upstream version) and updates the book
Alexander E. Patrakov
More information about the blfs-dev