LFS and BLFS
randy at linuxfromscratch.org
Sat Dec 15 06:52:23 PST 2007
Alexander E. Patrakov wrote:
> 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
> two configurations.
As I mentioned before, I believe XFCE to be the exception
more than the rule. And for XFCE, there would be nothing
wrong with stating "The instructions below will install
and configure XFCE to be used without HAL. If you wish
to use HAL for mounting removable media, you'll need to
install policy-kit and yada, yada, yada. BLFS has not
tested this configuration".
That way we present a known working configuration with
a mention of the other configurations.
> 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
> further steps.
Please keep in mind that one of the biggest features of BLFS
is the comprehensive dependency lists. Even if several of a
package's dependencies are non-BLFS, they are documented. That
in itself is huge.
> 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
> page. OK?
Sounds great to me. The Perl modules all have existing anchors
already. It simply means that the XFCE page needs to be updated
to point at the anchor (trivial).
> 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
> upstream version.
> 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
But you use XFCE, right? And you have capability to update the
book, right? :-)
But I do see your point. Take the LPRng package, I've updated
it, but I don't use it. I use CUPS. I've built LPRng, installed
it to a destdir, examined the installed files, but I can't swear
that all the programs work exactly as they are designed to.
This is a dilemma that will always be there in BLFS. We can't
be perfect, but we can try to do our best. For some packages,
that will have to be good enough.
A project with a scope as huge as BLFS is bound to have some
holes. There are literally thousands of packages out there,
many of which all do the same or similar things. We cannot
test or document most of them, as there simply isn't enough
time in a day. We can only do our best.
One thing I see that could be helpful is to list similar
packages (packages which do the same or similar things) on
BLFS pages. For example, on the K3B page, we could list other
packages out there that do CD/DVD recording. On the MPlayer
page, we could list other packages that are media players,
I like to look at BLFS not as an all-encompassing book of
facts, but instead a resource to help folks build packages,
and learn the basics of building open-source software. BLFS
will never be a resource that will provide instructions for
each and every package, it is only a resource that documents
what other folks have discovered, and then tries to get that
information out to others.
More information about the blfs-dev