Qrux wrote: > On Nov 8, 2011, at 5:06 PM, Bruce Dubbs wrote: > So, if editing the book is (comparatively) easy, what makes BLFS so > hard? The sheer number of packages?
Short answer, yes. A longer answer is that many applications are inherently complicated and the prerequisites of many packages rely on many other packages. Just look at Xorg. I think there are about 250 separate programs needed in order to get a basic graphical display. Also look at multimedia. there are tons of protocols and applications. Getting everything to work together is a difficult problem. Just look at pkg-config. You'd think that was easy, but the default build wants both glib and even pkg-config (yes, a circular dependency). Getting those right took some time. > "Distro" might be a dirty word around these parts, but it shouldn't > be. BLFS *is* a distro. Instead of checkboxes, you offer the user a > choice of typing in a command--or omitting it. The major difference > is that BLFS offers more control. That seems to be a defining > difference. So, choice is not the defining difference. The degree > of control is. But, the price of that control is not having > releases. Is that a good cost? Or just something we're living with? I have a little difficulty differentiating choice and control. They seem to mean the same thing to me in the BLFS context. The whole concept behind BLFS is to let the user choose. So yes, I think that is soemthing we need to live with. > I'm just trying to understand the causes for that cost. Calling the > cause "choice" is...imprecise, and leads to religious-type debates > about the virtues of checking boxes vs typing commands, which I'd > like to avoid. The problem with checking boxes is that you are limited to the boxes presented. One of my goals with BLFS is to help the user make choices, but another goal is to help the user learn to think for himself. > Even if packages are a little older than the current bleeding edge, > but packages A-Z are "released" together and work together, I think > that has value. Even if packages B and F and Q are a little old. If > you look at NetBSD and pkgsrc as an example...It's still a lively > community with active developers, because (AFAIK) what they are doing > is checking-in CODE. Not a book. I don't think the issue is trying > to understand what the vocal minority wants (the types that like to > tinker and hang out on dev lists). I think the issue is trying to > understand what the goals of BLFS are (perhaps in relation to LFS) to > make it a "live" project with active development. > > If the tinkerers aren't contributors, then they're fine with the > status quo (or they don't care). But, since we've already said the > status quo needs fixing, then we probably don't want to say: "Well, > the tinkerers don't care." That doesn't seem like a useful measure > of progress. Building a relatively full LFS/BLFS system takes quite a bit of time. Most people don't want to do that, at least more than once. Getting someone to go beyond and research a package newer than the one in the book takes even more time. The number of people that keep RH or Debian or Ubuntu up to date is in the hundreds (each). Most are paid. >>> 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'. > > I'm not saying I want a commercial distro. I *am* saying I would > BLFS to have releases, where the instructions for building the > included packages of each release are known to work with a particular > version of LFS. That would be nice. I'd like that too. > Come on...If you didn't care that it didn't "just work", you wouldn't > spend time testing whether or not the packages compile correctly, > right? So, obviously there's value to that. That's the same value > that any other distro has: "If you use these pieces, it 'works'." I > haven't heard of too many projects that never release--or communities > that seem almost against having releases--except for the projects > that don't make it. I don't want to see BLFS go that way, and I'm > suggesting that maybe it means changing things up a bit (or a lot). > >> 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. > > Well, can't that be done in many other forms? You say editing the > XML isn't bad. Fine. But, that's still time spent, right? If you > lower the overhead of what it takes to contribute, won't more people > contribute? What overhead? If people just posted to blfs-dev that said "I just built package-x.y.z and I had to change the instructions to..." I'd do the XML. I would test the instructions, but that generally doesn't take long. Except for X and KDE and Gnome... > And isn't part of the issue of BLFS that there are more > packages than people willing to keep them up-to-date? Let's say, for > example, that instead of a DocBook, it was a wiki open to developers. There *is* a wiki open to developers. We just have to give permissions because when we didn't, we got spam. Look for the link in every page. > Would you think it's easier or harder to keep that up-to-date (and > even take a "release" snapshot of) than the book? Could those > developers spend the majority of their time contributing their build > experience to making a package work (as part of a release cycle), and > a minority of it updating a wiki? A mail message would be even easier. > I'm just asking: "Really? Do we really need the book that badly? Yes. However, it is open source and you are free to do your own thing. CBLFS tends to do it the way you suggest. I don't mean that in a harsh way, but there are certain goals that I don't want to sacrifice. And after all, I'm doing most of the work. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
