Future work

A summary of some things talked about at OLS:

1. The addition of Fortran (!) does not have an
impact on the lsbsi.  I had raised the question
since the build produces gcc and g++ (only)
and does not download the full source tarball,
but there's no Fortran code proposed to be
built in the lsbsi.

2. nALFS code (added by the LSB team) to 
conditionally switch on a processor needs to
do something different than currently, where
the processor type is hardcoded at build time.
Chris Yeoh has updated to do uname and then
remap the answer from uname to the proper
strings in case they're different. This
better supports dual-universe type systems
where depending on how you run a binary
it can return two different values (e.g. on
ppc64, the answer from "uname -m" is different
than the answer from "powerpc32 uname -m"),
so a compiled-in value was problematic.

3. The powerpc64 architecture introduces
a new model for the lsbsi:  most of the
binaries and libraries on a ppc64 distribution
are in fact 32-bit, with the necessary
64-bit libraries also supplied, and possibly
a few binaries as 64-bit.  Some packages
that might go into a distribution (even a
mini-distro like the lsbi) have not been
tested as native ppc64 builds, and a few 
crucial ones such as gcc are known not to
build as native 64-bit programs. We don't
want to blaze the trails on those. In
particular, it's considered likely that
configure will do the wrong thing in some
cases, and we don't want to be debugging that.
Exception: a config.guess which knows about
ppc64 is an allowable patch if the base
package comes with an older config.guess.

There was some discussion of how to modify 
the build to accommodate this.  The proposal 
now is:

A ppc64 lsbsi will consist of a ppc32
distribution, plus the necessary additional
bits dropped on top to provide 64-bit
libraries.  It's possible to take a ppc32
distribution built on ppc32 as the base
of this, but as an experiement, at least,
building will be attempted on ppc64.

In order to produce the add-on libraries,
a new build sequence will need to produce
a ppc64 cross compiler and toolchain,
and them build and install the LSB libraries
to the appropriate path.  

We think the packages involved are:

X11: libGL.so libICE.so libSM.so libX11.so libXext.so libXt.so
libc: libcrypt.so libc.so libdl.so libm.so libpthread.so libutil.so
ncurses: libncurses.so
pam: libpam.so
zlib: libz.so
gcc: libgcc.so


NOTE: we suspect that the same consideration
applies to AMD64 - namely that an essentially
32-bit distribution with 64-bit libraries added
on top is an adequate solution.  The lsbsi is
not proposed to contain 64-bit binaries, but to
be able to run them, including the LSB runtime
test suite and the application battery.  Can
someone with AMD64 knowledge confirm or deny
that this approach would work?


Remaining to discuss is nALFS uplift to the
latest version, package version uplifts
(quite a few of the base packages have 
revved since the lsbsi stopped following
along when it became time to freeze a release)
and an lsbsi-based build environment.
In particular I'd like to think about glibc 2.3 -
is that appropriate for the next lsbsi (that
will match 1.9/2.0).  The lsbsi is believed
to already be C++ ready, as libstdc++.so is
already built and installed.

Build environment: a topic we've touched on
briefly in the past, is there value to a
"build environment" addon which would drop
a compiler and bintutils and maybe a few
other bits on top of an lsbsi?  


-- mats