[lsb-discuss] Multi-lib standards

[tytso at mit.edu]

One thing to keep in mind is that both RHEL and SLES is using /lib64,
and have been for quite some time, because of the backwards
compatibility issues, and the probably won't be changing it for quite
some time.  Debian/Ubuntu is actually a bit of an outlier in that they
didn't have multilib/biarch support for many years after Red Hat and
Novell had been very happily doing the /lib64 thing.

And given that there are some Atom chips which are 32-bit only, and a
number of people who tend to run 32-bit VM's (because they want to
conserve memory), there will be many ISV's who may very well decide
they only want to ship 32-bit products, just to simplify their
build/test matrices.

This actually brings up a problem for the LSB, which we've largely
been ignoring for some time, which is the statement we can make about
a 32-bit certified LSB platform working on a 64-bit distribution.  We
currently don't have a good way of certifying a bi-arch distribution
to be LSB compliant on 32-bit and 64-bit side of the world
simultaneously, and part of this is due to a short-coming in our test
tools, and part of this is a spec issue.

In practice, a 32-bit LSB compliant application will very likely run
on a LSB-certified 64-bit version of RHEL and SLES, and less likely to
run on Debian/Ubuntu, because of their historical approach to
biarch/multiarch.  At the moment we're waving our hands on this issue,
and I don't think a realistic solution is to assume that 64-bit "pure"
systems are the wave of the future, and that 32-bit applications will
disappear.  That potential future would be convenient for
Debian/Ubuntu systems, certainly, but I don't think it's likely one.

	      	       		      	      - Ted