BLFS-6.4RC1 or any
rjwaldren at gmail.com
Wed Feb 17 10:11:53 PST 2010
On 2/17/2010 6:32 AM, Randy McMurchy wrote:
> If the community's expectations are that we have the most current
> release of every package in the most recent BLFS book, then the
> expectations are too high and are unreasonable.
> Do you really think there will be that much difference between
> GNOME-2.28 and GNOME-2.30? Enough to say BLFS is "out of date"?
> I don't think so, but that is just one man's opinion.
This is the main sticking point for releasing a BLFS that I see...Just
my thoughts on the subject but Ill' throw them out there.
I've never spoke up but every time the "BLFS Release" discussion comes
up I think "Targeted Version Freeze". At some point, maybe in the LFS
release cycle, define the versions of major package groups that will be
targeted for BLFS and branch. Only allow security and well reasoned
updates that exceed the the targets into the branch. I'm not talking
about every package in the book, just the major items, KDE, Gnome, Xorg,
Mozilla apps, etc. Most of the other common apps are at least feature
stable and don't generally cause an upheaval when they make new
releases. But trying to ensure support for KMS or yesterdays newly
added codec in FFMPEG is a fools game - let it stabilize in the wild
first and the project dev's can take care of the growing pains.
So often, I see DJ and a few others, working so hard through some very
involved package groups only to immediately move on to the next
release. Not a dig at DJ, he does great work and works hard. But I
think it would be a little more relaxing if he had a defined target,
rather than trying to keep up with so many divergent projects. After
stabilization and release, trunk will take off again and maybe have to
skip a release for some packages - but at least there won't be all of
this work going on that is just replaced before it ever sees release.
i.e. - Defining a target of the current stable gnome, kde, and xorg,
this will indirectly define minimum versions of most supporting dep's
included in the book. And work can go into stabilizing rather than
Another idea is to not worry about versions at all. Only build test and
update packages as required to maintain parity with LFS and security
errata. It may not be bleeding edge but it would certainly meet the
educational goal and provide a usable system. Major updates could still
be done as it it makes sense to do so, feature-wise, not just because
the external project made a release.
More information about the blfs-support