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 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
