On Mon, Aug 01, 2011 at 10:59:02AM -0500, +Jan wrote: > > Perhaps what is needed is a way to easily determine what is broken and > what is not. There seems to be a split consensus of whether releases > are necessary or not. If BLFS was to do a release in the near future, > I think the easiest way would be to mark packages with a category tag > of some sort indicating the status of that particular segment of the > project. As purely part of the suggestion, here's three categories I > think would be useful: > > * Stabilized (tested against the current LFS) > * Unstable (as in no longer builds against current LFS) > * Development (as in new to the book and YMMV) > That was part of the thinking for the tags such as - This package is known to build and work properly using an LFS-6.7 platform.
Of course, since BLFS hasn't managed a release, the older tags are not tremendously helpful. However, the absence of a tag may indicate that nobody cares about a package. The problem with "tested against the current LFS" is that you can only do that after an LFS release - all sorts of version increments in LFS sometimes have knock-on effects. I would hope that anything added to BLFS will at least build with the current LFS release. Of course, when LFS upgrades the toolchain, all manner of things break. In those cases, as with looking for security fixes, builders need to look at the distros. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
