I think the main problem is not keeping the BLFS instructions up to date with LFS, but keeping it consistent on its own. More comments inside.
On Tue, Nov 8, 2011 at 11:17 PM, Bruce Dubbs <[email protected]> wrote: > In the last three weeks, I have updated about 64 packages in BLFS. I > started to look ahead. This is where we stand: > > LFS 7.0 checked: 64 > LFS 6.7 checked: 97 > LFS 6.5 checked: 143 > > There are, in addition, somewhere around 320 packages that have no > annotation. That is a total of about 625 packages. How many of the 6.5 instructions will work on LFS 6.5, considering that at least some of the prerequisites are already updated to 7.0. My guess is that many can be anyway, and most can with small or easy changes. The question is, how can a user know which is which. Any of the regular developers can check and update the book if necessary, but most users don't know enough to do so. The problem I see is not that there are packages that aren't updated for LFS 7.0, but that anyone who wants to use LFS 6.8 in order to have more package instructions, won't have a consistent path. > Another statistic is that the pdf version of BLFS as 1481 pages. Does anyone print it? I would guess a pdf would be more useful if it lists packages in installation sequences, similar to what LFS is. Creating such pdfs shouldn't be that difficult, but since I don't need a pdf, and I don't plan (for now at least) on working on that, I won't elaborate on how I think it should be done. > I will continue to update, but I'll probably slow down as what I've > already done has a lot of relatively simple packages (and a few > not-so-simple ones). It's your time. Naturally we appreciate the work you did, and do in the future, whatever pace it is. Thank you. > What has been obvious for some time is that we cannot produce a BLFS-x.x > release. First, there are not enough developers with the time needed to > do the necessary work. Second, and probably more important, is that > with the number of packages in the book, the change rate is just too > great to produce such a book in what could be called a timely manner. The main problem I see with the current design, is not that a release cannot be produced, or the change rate, but that there is no way to keep work which was already done up to date. That is something which I hope to work on, so I'll provide some details about what I think should be done. I hope to start working on it in a few weeks. I would like to create an automated way to test that instructions still work after a dependency is updated. The general idea is that as soon as LFS is updated, (tests could be weekly, and hopefully before a release) the BLFS instructions can also be tested, and instead of tags of last known to work in LFS x.x, we can find out that a package is broken as of this date. The basic system state would probably be LFS+liveCD+LFS building tools. These would be used to build clean updated updated versions of itself, and this would be used to build other package paths. > > I am proposing to send out the following announcement: > > --------- > > BLFS is announcing a new release methodology. The book will not be > released as 'stable' or 'development', but will be produced in an > ongoing release cycle. The book will be entitled "Beyond Linux From > Scratch - Version yyyy-mm-dd". New versions of the book are rendered > daily, but the version dates are only changed as content is updated. > > Most package build instructions in the book will be annotated "This > package is known to build and work properly using an LFS-x.x platform." > This will give users an indication about when the package was last > updated. In most cases, older instructions will work with little or no > modification on more recent versions of packages used in the book. Sounds reasonable. I would like, as mentioned above, to also be able to say when instructions broke. > In addition I can update the web site to reflect this change. There > would be no regular pdf or nochunks versions of the book, but a tarball > of the current book's html will be available. These should probably be created but not as often. (monthly?) As mentioned above, I think these should be created for some package sequences, but not necessarily for the complete book. > The current changelog goes back to August 2008. I propose removing any > log entries more than about a year old and save them in a separate file, > but not publish them. The current changelog is about 40 pdf pages. I would restart the changelog from when you started updating for LFS 7.0. --yaacov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
