On Nov 8, 2011, at 5:06 PM, Bruce Dubbs wrote:
>> effort (not to mention the innate combinatoric complexity of managing
>> references).
>
> LOL. Did you *read* the last sentence? Try saying it out loud. :)
Haha--I do ramble, don't I? LOL
I'll try to be terse.
>> 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...
>> 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, if editing the book is (comparatively) easy, what makes BLFS so hard? The
sheer number of packages?
"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'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.
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.
>> 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. I'm not sure how
that comes off sound like: "I want RedHat/SuSE/Gentoo/whatever."
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? 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. 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?
Excuse the paraphrase, but it sounds like this to me: "Well, we need to have a
book. Therefore, we can't release the contents itself (in any other form),
because we have to have the book. So, we sacrifice releases because we need to
have a book. And that book is so large that we can't release that, either.
So, there are no releases. And that's the way we need it to be."
I'm just asking: "Really? Do we really need the book that badly? Isn't it
better to focus on the release of the contents themselves (and I'm only
suggesting other formats as alternatives, if indeed the book is the issue), and
leave the book as something that reflects the state of the contents?" For
instance, focusing on the code (patches, build scripts, testing, etc), and
leaving the book as a separate exercise?
Sounds like you're saying that the goal of BLFS is in teaching people how to
build a system. And I'm asking if that's how it should proceed, given the
issues we've brought up in many previous exchanges.
Q
p.s. I'll try to be less repetitive in the future when responding to your posts.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
