RFC: BLFS-6.4

Ken Moffat zarniwhoop73 at googlemail.com
Sat Jul 18 16:15:44 PDT 2009


New thread, for what I'm suggesting.

1. Create a branch for 6.4  Something needs to be done to get it to show up
on the website, and to render.  I've no idea what that involves.


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.


3. Somebody needs to manage the release.

 I'm reluctant to step forward because (i.) I'm hoping to be away a lot in
the rest of the summer, which will delay the process, (ii.) I got fairly
pissed off patching old versions of e.g. poppler for vulnerabilities before
6.3 came out, (iii.) I really want to try newer versions of those packages
I use in my current builds, (iv.) I want to try some ppc64 toolchain stuff,
and (v.) I hate branches in svn as much as everyone else does.

[ 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.  Releasing when there are _so_many_
open tickets for version upgrades is not a sensible idea. ]

 But on the other hand, I do have a 6.4 system (packages, and versions,
listed at http://www.linuxfromscratch.org/~ken/desktop-2009-06/ ) so
I've got experience with some of these packages.  Note that my gnome
stuff, such as it is, often uses 2.24 not 2.24.3 - I find the point releases
are usually only extra translations so I tend to stick with whatever was
current when I last looked.

If this proposal (for a branch), and my offer to manage its release, is
acceptable, I'll be looking to cut an -rc in mid October.  That can either
include packages with status "untested", or they can be relegated to
external links to their home pages.  For packages which fail to build
and have not been fixed, I guess they'll have to be relegated to
external links.

Looking at the current book, about 3/4 of it is things I've not
tested (I ignore kde3 here because I think it was updated against
6.4).  Some of these are things I can build with a DESTDIR install
and then discard, others aren't (dependencies on things I refuse to
install).  So, if I do this then the result will be a smaller book, perhaps
a lot smaller).

Thoughts ?

ĸen



More information about the blfs-dev mailing list