FINISHING lsb-si for LSB 2.0

Yes, it's time to talk about that again. I have 
to admit, we thought we could put the lsbsi off 
until now and get it done quickly, and it's resisted 
our efforts at getting it done quickly.

So there's been a lot of work recently, and
yet it's not done, and we're kind of approaching
a point where we need to wrap up the major
changes and move it out towards a testing status.
I keep trying to update the status in various
places but the great thing about lists is they
always go out of date, so here's a fresh cut at
what I see remains to be done:


1. Complete generic work for platforms that
need to put libraries in paths ending with lib64.
At this stage, things build well enough that
examining the contents of /lib and /usr/lib on
platforms that ought not to have libraries there
is probably the best way to identify the rest.

2. Complete architecture-specific work for the
three platforms that have not released an lsbsi
before (x86_64, s390x, ppx64), if there's any
that doesn't get covered by (1) above.  This
work has "owners".

3. Complete uplifting of base packages to latest
upstream.  The remaining candidates are as
follows; it's possible that these don't all
(or any) have to be done:
gcc 3.3.2 -> 3.3.3
ncurses 5.3 -> 5.4
bison 1.35 -> 1.875
gettext 1.12.1 -> 1.14.1
sed 4.0.8 -> 4.0.9
shadow 4.0.3 -> 4.0.4.1

4. Complete examination of alternative build of
X libraries, using unbundled freedesktop.org
versions instead of bundled XFree86 versions.

5. Sanity-check step: bootstrap and phase3
install to an "alternative root".  During 
this round of lsbsi work, a number of cases
were discovered where the logic is not correct:
they /configure/ for an alternate root, and
then do "make install", where it should configure
for a standard root, and then install to the
alternate.  Most packages support this type of
install with DESTDIR= but not all.  These may
all have been fixed but someone should check and
fix the rest.

6. Modify the coreutils phase3 build to install
only the tools required by the LSB.

7. Examine the final build for extra libraries
and binaries, and especially extra shared
libraries which might not be needed, and
eliminate if it makes sense.  (A partial
analysis already exists).

8. For all one of the platforms which support
UML, examine the correctness of the lsbsi-uml
package, which has not been looked at for
many moons.  Since it just bundles up the
lsbsi plus addon problably the contents are
okay, but there are questions whether it will
interact well with current versions of uml,
device names, setup script, tt vs skas mode,
COW support, and a variety of such questions.

9. Rearchitect the package currently known as
lsbsi-lsb, which is designed to install the
package dependency stuff, so that it fits the
new multi-architecture, multi-version support
that the LSB requires, and get those packages
released.  If possible, also pull in copies
of install_initd and remove_initd, required
by the LSB but currently missing from the
lsbsi.

10. For all the platforms, run all the currently
available tests and examine the results (also
includes installing all of the appbat packages
and checking them for correct behavior).  The
2.0-level tests are going to start becoming
available next week and should all be in 
beta/pilot by March 15.


It would be nice if we could develop a plan of
attack for all of this (plus whatever else I've
forgotten - please help fill in the blanks) with
who's interested in working on what.  We've had
some offers of help which is great, because it
looks like we'll need it - this is a good time
to step forward.  Issues like cvs commit access and access to non-ia32
machines
can both be taken care of as needed...


Mats

P.S. - I'm on travel part of next week and
have to do some non-LSB work so my time is
going to be limited a bit.