Dan wrote:
> I hope no one resents my "uninformed" intrusion into this discussion.
> This may be long, so I ask forgiveness in advance.
Don't worry about either count. Such discussions are often between
developers or potential developers, and the views of the "regular users"
is forgotten. It is refreshing to see such a perspective, as released
projects are released for "regular users" after all.
> 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
I wouldn't be so sure about that. I'd bet that with a little bit of training
and learning you could "become" talented and knowledgeable enough
to be involved.
This discussion indirectly deals with this issue.
> 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
I believe this is due to the "developer" bias of discussions on development
lists I mentioned above.
> that I'm a user--I understand and agree with LFS *as it exists today.* I
We (at least Jeremy and myself) are referring to package management in
a way that won't affect regular users at all, except for another optional
command in each chapter, similar to the current "make test/check"
commands available today.
> 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
We are trying to make it easier to make your own rules. We use the
term package management because we want mostly the same actions as
package management provide, but for different purposes. We want to be
able to keep track of our own work, and learn what we can from the
"packages".
If I understood you correctly, you exactly follow the book, learning during
the process - which is good - but using the LFS rules, not your own.
> 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.
That is a healthy view as a "regular user", but imagine doing that twice a
week, just because you feel like experimenting with some rules of your own.
> 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
Correct. What we are talking about is making it easier for someone to
repeat his OWN individual work.
> 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.
That is actually a reservation I have from Jeremy's method. It is simple, but
it becomes part of the installation process. I would prefer a method which
after each installation does some bookkeeping. This wouldn't affect any
installation, and anyone who wanted to, could just ignore the output, or even
skip the package management step.
> and testing. Where is LFS going to go from here?" Maybe the answer is
> "nowhere." That doesn't mean it won't be viable.
Maybe the answer is "nowhere", and LFS will stay viable, but this is no way
to involve new users. The thread left the topic of the website to the future
of LFS, when Jeremy (who if I am not mistaken designed the new site) basically
asked why so few people are involved in LFS. I assume Jeremy redesigned
the website partially in order to make the community "more dynamic and
sharing" (to misquote him), a goal which is bound to fail if the answer is
"nowhere".
I mentioned above that I'm sure you can achieve the qualifications to be
involved in LFS, but I am not sure there is any point in getting involved.
> 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
That is the current state of affairs, but all the other projects (with
the possible
exception of BLFS), which (I think) were run by active members of the LFS
community are basically dead.
> 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
I'm sure you can.
> 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.
Again, thanks for a fresh perspective, of the kind often missing from such
discusstions.
--yaacov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
