rprogers at seanet.com
Thu Jan 29 16:36:35 PST 2004
On Thu Jan 29 15:26:39 MST 2004, Archaic wrote:
> And since this is a roadmap thread, I would like to pose to Gerard that
> since *many* of us have, will, or currently are building production-type
> or at least stablilty-necessary machines, we should consider keeping the
> 5.x branch alive (at least in package updates) until the 2.6 kernel
> matures. I'm guessing around 2.6.12 going by when people in large
> numbers starting migrating to 2.4 from 2.2). Of course, that may mean
> using an older toolchain (much like we do for building the kernel) if
> the toolchain packages should make a make a major upgrade. That leaves
> us off having to expend too much time on the then-secondary 5.x branch
> (unless enough people clamor for it and it's deemed worthing of active
> Comments? Opinions?
I too would like to run a stable production "don't upgrade anything
unless I have to" LFS machine. I've kind of waivered back and forth
about suggesting that the LFS project support that. My current thinking
is that LFS should be just an educational book, not a Linux distribution.
As such, it should tell the reader how to keep their system as up to
date or safely out of date :) as they need it. Users who need stable
systems but lack the skills to keep their system updated appropriately
(perhaps with a _little_ help from lfs-support/lfs-security) would
probably be better served by a more traditional Linux distribution.
Of course, if someone wants to start an LFS Distribution project,
that's another story :)
So I vote for a model where there's only one supported LFS release.
It gets bug fixes and minor package updates as appropriate while
development proceeds on the next major LFS release. Older books
should remain available, but unsupported. Perhaps some text added
to the book or a hint explaining what to do to keep your LFS system
on the (bleeding|leading|trailing) edge.
More information about the lfs-dev