2009/7/19 Ken Moffat <[email protected]>: > 2. Within that branch, label each package (on its page) with a status. Things > like: > > seems ok (i.e. tested on this version of LFS, the instructions > work and no problems have been identified) > > builds, not tested (i.e. not tested in use) > > not tested > > fails to build (i.e. for this version of the package) > > builds, with other problems (I suppose those should be noted on the > wiki?) - a tricky concept, it would be easier if I had an example! > > no longer supported upstream (a bit of a killer - e.g. for the demise > of firefox2 in BLFS-6.3 systems) > > known vulnerabilities, use a newer version if you can > For a release, this implies either finding a patch/workaround > or dropping this package.
[...] > [ Actually, that reminds me - if we branch 6.4 then update a version there > it isn't a straightforward job to get that back into trunk - ignoring the > build size and time which might be inappropriate (just like everything that > is currently in trunk, for an LFS-6.5 base) there is the new 'status' field > which doesn't belong in -trunk. > As an alternative, replace "status" with 'last built against LFS version ...." (and show the release or svn date) - that has benefit going forward that it indicates what might not build with a current release, or might have outdated space and time figures. Loses information about how well it was tested, but since we don't hold that information at the moment it's no big deal. ĸen -- After tragedy, and farce, "OMG poneys!" -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
