On Mon, Aug 1, 2011 at 3:38 PM, Ken Moffat <[email protected]> wrote: > 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. >
Very good point. I guess whether things have been tested or not would have to be flagged as untested every time LFS pushed a minor release or errata, especially when talking about the compiler tools and libraries. Even if the tags were automatically reset through xml processing somehow, it would still mean a complete check of the book on version changes. With that in mind, it definitely seems better to flag the last version of LFS a package was built against, instead of some obscure development flag. > 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 As someone who wants to help BLFS I was just thinking it would be useful to have a faster way to determine what needs work and what doesn't without flipping through every single page. Tags on the development index indicating the last good build versus LFS (eg. a fancy [LFS-6.8] flag) would be helpful for someone who doesn't use the automated approach. If the metadata is missing, then no tag is an indication as well. If a release was cut it would just be a matter of omitting any of those tags from the final rendering. I'm not sure how the tags you're talking about are actually implemented though, Ken. I haven't looked at the xml version of the book in a couple of years. They might be implemented on the page level, complicating propagation outside of the individual package pages. Jonathan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
