Bruce,
I'm on your side, at least I think so--whatever little difference that may
make...
On Nov 8, 2011, at 8:21 PM, Bruce Dubbs wrote:
> 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.
Just as we're limited to what's in the book, right? That's a distinction
without a difference, really...I think the control comes down to HOW individual
packages are compiled (which is usually not an option in most checkbox systems:
e.g., PHP with Postgres but not MySQL support, with zlib, but not SSL, etc).
>>>> 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.
Then, have that be a goal. Because later on...you say something else...
> 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...
So, I'm missing something. If that's how easy it is, then you're just saying
people don't want to contribute the instructions for the package? There's
little else that needs doing?
>> 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.
No, no--I appreciate the candor. That's what I'm looking for. And, that's
sort of my point exactly. It's your work. It's your choices that filter down
to become "our" choices (i.e., the people using BLFS). So, make choices.
Choose the 100 (or 50 or 200) that get you to the goal of having a release (a
set of packages that you know works). You've got yourself between a rock and a
hard-place, where you want to give people arbitrary amounts of choice
(arbitrary because in the context of BLFS, they can only choose the packages
that are presented anyway). If they wanted that, they don't need BLFS in the
first place; they can just compile everything from READMEs.
I don't think it makes sense to say you want releases, but then say you can't
because the book doesn't allow for it or because you want to give people
infinite choice, right?
I think your efforts are great. I just think you don't need to hem yourself
in? Make choices. It *is* your work. I think you can make choices. And
should. Tell us what 100 packages you'll do (or however many), and then force
people to contribute when their armchair "choices" become so important that
they're willing to contribute some content. I mean, maybe I don't like your
choice of MTA. But I'm sure as hell not gonna whine about it unless I send you
a patch, right? Per your suggestion, I will check out CBLFS, too. I do
appreciate knowing exactly what your motivations are.
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
