On 07/28/2010 10:36 AM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>
>> On Jul 28, 2010, at 1:07 AM, Bruce Dubbs wrote:
>>
>>> Section 6.3 discusses PM. It says why we don't have PM in the
>>> book.
>>>
>>> There are six hints on PM.
>>>
>> These sorts of replies are discouraging. It says "we've dealt with
>> this, no point in discussing further". It's terse and official and
>> unwelcoming.
>>
>> Yes, we know what the book says. All of us discussing this topic are
>> well familiar with LFS, (including Yaakov, you can easily see that
>> from his comments). And we know this topic has been discussed before
>> - so saying bluntly that the book deals with it as if that should be
>> the end of the story doesn't address why this topic is being
>> discussed again now. Obviously some people disagree with 6.3 and its
>> reasons and they feel that despite what is said there may be some
>> advantage to adding something more about PM to the book. If the end
>> result of the discussion is once again that things are best left as
>> is, that's totally fine, but let the discussion happen. Be open to
>> the possibility that a previous decision is no longer applicable or
>> that perhaps now is the time to reconsider.
>>
> I'm not opposed to someone creating an alternative version of LFS with
> package management. If a volunteer needs the resources on the LFS site,
> I'll be glad to set them up. However, I don't want to work on such a
> project.
>
I hope no one resents my "uninformed" intrusion into this discussion.
This may be long, so I ask forgiveness in advance.
I'd love to be more involved in LFS, but I don't think my talents and
knowledge permit that. I'm a user. I "lurk" on the lists to get the
pulse of what's going on. I think that this is a cogent discussion and
that the outcome will affect the direction of LFS--or any future projects.
Over the years, I've seen a few discussions like this and a lot of them
seem to end up with a discussion of package management. Package
management seems to be a "third rail." Additionally--please don't forget
that I'm a user--I understand and agree with LFS *as it exists today.* I
think that the stated purpose and the phrase "your distro your rules"
are the key to LFS. It's not for "unblooded" beginners. It's not meant
to provide a complete "push a button and you get everything." I have
LFS-6.3, with BLFS-SVN at the time of the build, running on my PC and
another laptop. Both do really well with no problems. The only reason
I'm building now is that I have a new laptop and the kernels of the 6.3
era don't support my hardware. My logic--if I need a new kernel, I might
as well use recent packages. I see no need to stay "cutting edge" when I
have an "up and running" system that does everything I want it to do.
But each time I build--from the book and by hand--I hone my command-line
and scripting tools. I think that this latter is one of the side, or
maybe even main, purposes of LFS. I *always* learn. Yeah, the
"./configure, make, make install" routine is pedantic and boring. But
it's the notes and command explanations and the troubleshooting and the
solving that make {,B}LFS a worthwhile experience in my mind.
If there are those who want "push a button and get a complete
graphically enhanced and outfitted system," then my response is get
Fedora or Ubuntu or Debian or Slackware or Suse. The LiveCD used to
build on an individual's system and then supply the tools for that
individual, as a host system, to build the basic LFS system. I thought
that was pretty good. And there's a discussion going right now on the
LiveCD list about what direction that project should take.
So far it probably sounds like I'm agreeing with Bruce. I am. But I also
agree with Jeremy and Yaakov. I'm reminded of a little speech that I
used to give my troops in the Navy, "If it ain't broke, don't fix it.
Clean it. Polish it. And maintain it. Keep it working. Don't fix it
until it breaks." IMO, LFS "ain't broke." But is a free open discussion,
an exchange of ideas, necessary? Yes!
Going back to package management. To add a package management system to
LFS, at least in my mind anyway, eliminates the ability for me to use
whatever package management system I want and, therefore, blunts "my
distro, my rules." Do many people want package management? Yes. Should
it be available? Yes. Should it be part of the basic LFS? I don't think so.
I think it's important to do what Jeremy suggests and "think outside the
box." I don't think the only option is "change LFS" or "don't change
LFS." What's "win-win?" Yaakov expressed some really great ideas, and
one thing he said really "jumped out" at me. This is not a direct quote,
but a repainting of the picture in my head after reading his posts. "LFS
is well developed and doesn't need development, but merely maintenance
and testing. Where is LFS going to go from here?" Maybe the answer is
"nowhere." That doesn't mean it won't be viable.
One might say then, "Well, Dan, how do we, in the 'LFS way' provide what
other users want LFS to provide?" The direct answer is, "I don't know."
However, I would be terribly remiss if I offered a criticism and my
opinion with no door to a possible avenue of solution. Therefore, I've
thought of this--and I don't know, from an infrastructure standpoint,
how to accomplish this. I do know that it deviates from what exists now
and is, therefore, "out of the box."
What about a "modular" approach to LFS? Just off the top of my head the
modules might be, in terms of current projects: basic LFS, package
management, LiveCD and JHALFS. Keep BLFS out of it for now. BLFS is the
"bells and whistles"--it is not my intention to denigrate or discount
all the work that goes into BLFS, but the key word is "beyond." A
"modular approach" allows a user to "pick and choose" what a basic
system looks like, and, IMO, takes "your distro, your rules" to a higher
level or more refined state.
Like I said, I'm a user. I don't think that I can be a developer and
maintainer unless I can follow written instructions. My thoughts are
presented with the mind set of "polish, clean and maintain." I also hope
I'll be forgiven for sticking my nose in where it might not be wanted.
Maintain the discussion!
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
