BLFS-6.4RC1 or any

Rod Waldren 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 
version chasing.

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 mailing list