BLFS release (?)

Alexander E. Patrakov patrakov at
Fri May 9 03:18:17 PDT 2008

Randy McMurchy wrote:
> I do not want to get into a situation where if someone follows
> LFS stable, we need to tell them to pull SVN sources from XYZ
> day and render it yourself in order to find a combination of
> packages that is compatible with one-another.

The compatibility problem automatically goes away if the books are merged (i.e.: 
there is no stable LFS, and LFS + BLFS are the same thick book). More details, 
to be considered post-6.3:

Notice that the unstable version of LFS evolved from the stable one through a 
number of potentially destabilizing changes affecting an unknown apriori amount 
of packages (e.g., new version of gcc or db), and a number of well-localized 
changes (e.g., new version of bzip2).

So, the proposal is to keep LFS and BLFS as a single book, and when a 
potentially destabilizing change is going to be introduced, make a branch with 
only this update, and comment out all potentially affected packages in this 
branch (with "new gcc" and "new kernel headers", this does mean "comment out 
everything"). Then, during the evolution of both branches, uncomment packages as 
they are verified to build and function correctly by at least one editor that 
works on this branch. Drop the old branch as soon as no "important" packages are 
left unverified. Maintain a list of such branches somewhere on the web site, 
render all of them, maybe keep periodic snapshots.

Alexander E. Patrakov

More information about the blfs-dev mailing list