Ken Moffat zarniwhoop73 at googlemail.com
Sat Jul 18 17:36:15 PDT 2009

2009/7/19 Ken Moffat <zarniwhoop73 at googlemail.com>:

> 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.

After tragedy, and farce, "OMG poneys!"

More information about the blfs-dev mailing list