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 > accordingly. 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, etc., etc. 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. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
