Qrux wrote: > Before proceeding further, I'd like to understand the nature of the > effort you just put into BLFS. I see the development of BLFS as a > somewhat different activity from LFS, despite the fact that both use > the same medium of DocBook. I would guess that become of > dependencies (or lack thereof) LFS is a roughly linear effort, > whereas BLFS (with its philosophy of supporting each package in both > standalone- and used-along-with-package-X-modes) is a combinatoric > effort (not to mention the innate combinatoric complexity of managing > references).
LOL. Did you *read* the last sentence? Try saying it out loud. :) > It would seem to me that BLFS, then, exposes this combinatoric > complexity mainly in the book. > > So, I'm wondering: "Is editing the book; i.e., keeping the SGML > DocBook up-to-date, the main time sink of developing BLFS?" No. That's relatively easy. The process I use is to check for the latest version, download it if necessary, check my build script or create it, generally to a DESTDIR, check the files that are created, install the package, run it if appropriate. If it is a server, the bootscript needs to be updated and tested. > * * * > > IMO, LFS has two products: a working system, and the book--which > serves as documentation and an educational resource. This working > system is as important a product as the book. But, because the > effort to develop and maintain the LFS book is roughly linear (yes, > this is my assumption/inference), it doesn't get bogged down by > itself. Linear? Not really. Some packages can be checked in 15 minutes. Others need a day or more. For instance mysql took a long time because it had converted to a cmake based build. I had to do cmake first and it took several times to get the mysql instructions right for publication. > In addition, I don't walk away after following the LFS > instructions with the feeling that I have to tinker. While that > feeling is obviously personal and subjective, the after-taste of > going through an LFS build is that it's "solid". That I "don't have > to tinker." And, instead, that: "I'd rather not tinker, because it's > known to work." Yes, it is meant as a foundation for building a working system customized for the user. There are changes that could be made to LFS. For instance, if you don't want i18n, then that can be removed. > BLFS also has two products: working packages and the book. But, in > the case of BLFS, the book seems to be the main source of the effort > (likely due to the nature of the complexity of supporting so many > packages). It seems clear that only when someone wants to build > "Package A" using "Package X" as support does the book need to > require a paragraph of description and a code segment to describe how > to build A with X. My point is, it takes someone who actually cares > about "A with X" to require its inclusion; so, the process of testing > "A with X" already has a human resource behind it. In addition, that > person could probably produce a README or a MediaWiki entry (just > some stabs at alternatives). I would imagine, then, that the issue > with BLFS is that to finalize the inclusion of "A with X"--into the > BOOK--requires writing SGML, maintaining the references, blah blah > blah, and that starts to require much much more manpower. The contents are the problem. The book source (xml, not sgml although strictly speaking xml is a subset of sgml) is not. The xml uses a DTD of docbook. It is important to have it in a form we can manipulate. It's what makes jhalfs possible (for LFS). It also produces wget lists, and enables things like the list of packages not on the BLFS file server (that I need to update). > So, in constrast, with BLFS perennially in the "non-release" state, > it *always* feels like tinkering. And, that doesn't seem right. The problem is that it is inherently complex. What one person wants, another doesn't and vice versa. We give choice, but that means the user has to choose. It's not always easy. > LFS--and by extension BLFS could be a very usable Linux system that > doesn't make people feel like they are "tinkering". If that's what you want, use a commercial distro. LFS/BLFS is about customizing and doing things 'your way'. > While I realize > certain people have legitimate security concerns, I don't see how > they are any worse than with common distros and the ways that casual > admins use them. A "release" of some subset BLFS makes it clear that > it works with some version of LFS, and quells the feeling that > something needs "tinkering" at a very low level. Even though how one > configures a package is dependent on the capabilities compiled into a > package, I don't want to worry that my package was compiled > incorrectly and will cause my app to fail, or that some strange set > of dependencies which was at some random revision in SVN--is going to > introduce subtle errors into my application. That is the purpose of > a release. I agree in some aspects. That's why we don't use development versions unless we have to. However, coordinating 600 packages takes more effort than we have resources. If you say cut it to 100 or 200, the question becomes which subset. Everyone wants something a little different. > Now, my assumptions are mainly based around this point--that BLFS has > combinatoric complexity, and that the book captures--and thus > requires--the effort to resolve those complexities. If this > assumption is false, then my later assertions are equally false... You are not completely wrong, but what we do is reduce the complexity a lot. Try building a distro by yourself without LFS/BLFS. Sure there are things like Gentoo, but I think we explain things a lot more. I am interested in conveying understanding for those who want to know. The rest of your post was somewhat repetitive and I already answered most of the issues. I do appreciate the feedback. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
