The state of lsbsi for LSB 2.0

After devoting a bunch of time this week to
working on the lsbsi, I'm going to have to
stop again, as I have a load of reports, papers,
and other such looming before I head out to
Linux World (where not much will happen on
this, either).

So here's a summary of the state:

- most of the packages have been uplifted to current
versions, most significantly gcc, glibc, bintuils
and coreutils. glibc-2.3 is the basis for LSB 2.0,
so this was a nasty piece of lifting that had to be
done at some point.  There are a few more packages to
update, but I don't think they're in the critical
path the way gcc/glibc were.  I got most of the
trivial ones; the remaining ones may have an LSB
patch that needs to be evaluated. I didn't finish
the coreutils work; the old fileutils/textutils/
sh-utils combination had some cleanup work to
remove non-LSB binaries in the final phase.  In the
interest of just getting it going I didn't try to 
forward-port that. We should just be able to evaluate
the list of installed binaries (I think I still have 
a reverse-mode cmdchk that reports on non-LSB binaries)
and put back the list of ones to remove. 

- I've crafted in support for the other architectures
where it looked like it was still needed (some places there
were four, some six, some seven); thus we're somewhere
in the neighborhood of being able to do a basic build
of the code for all seven.  It's not correct for the
complex ones (ppc64, s390x, x86_64): the multi-
architecture work is not done.  I wanted to just
try the builds first and see how much works out right.

- I've done a test build on x86_64; the bootstrap 
completes, but the gcc spec file was not edited
correctly, so that the first dynamically linked exectuable
that actually gets run fails because it has the wrong 
dynamic linker. I've just fixed this in the xml,
I misunderstood something about the nALFS (old version)
syntax.  Hopefully a rebuild will go better.

- something funky has happened to kernel headers
since 2.4.22 on ia64, with the result that even
the bootstrap won't complete on ia64.  I introduced 
this problem: we used to fully configure the kernel 
before grabbing the headers for the bootstrap; I
changed to the current way LFS does it, which doesn't
end up actually configuring the kernel.  And that
works great except for the crud one of the kernel 
headers on ia64 aquired to make sure a valid page 
size is being used: if you haven't actually /selected/
a page size, it dies. 

- the rpm that's used to initialize the rpm database
has been updated to 1.9.0 (I used the autobuilder
images), but this rpm doesn't yet really have the
right contents for LSB 2.0 - todo.

- I plan to evaluate the LFS patches to see how
many of them are applicable to us.  The glibc
patch was clearly needed (glibc 2.3.2 wouldn't
build without it).

- And it all needs testing - on all the architectures.
I'm only reasonably able to do 386 and ia64 here.
I may be able to kick off an lsb-runtime-test run
on x86 before I have to put the toys away.

- and a final note: this stuff is in quite a fragile
state at the moment.  I had several things that
refused to compile at all on various test architectures;
lifting the versions seems to help.  binutils is a bit
out of date; 2.15 is in the pipeline and fixes a number
of issues on newer architectures (I'll have to ping
HJ Lu to see if there's a target date). We're on 2.14
now, previously we were on 2.13 which was way too old.
There is likely to be further breakage as we get to
looking at this on all the architectures.

Also, the bootstrap requires some interesting static
libraries.  On one platform, grep wouldn't link because
there was no libpcre.a.  I don't, at the moment, have
a complete list of what's needed; we should probably
expand the configure script to check for these like
was recently added for the application battery.