FWIW, my use case for multiarch is not "sharing the root filesystem
among multiple systems". It's "sharing the non-lib namespace (/etc,
/bin, data) among multiple instruction sets / ABI variants on the same
system". I don't need (/usr)?/s?bin to be decorated with a triplet,
because the kernel picks a fresh ld.so variant at the execve() boundary;
I am happy to mix ARM and x86 binaries (and Python and shell scripts) in
/bin, and let the kernel (and binfmt_misc + qemu) sort it out. I only
need (/usr)?/lib to be disambiguated *at runtime* because ld.so is not
as smart as the kernel. (It's not just ld.so, of course; module/plugin
loaders for everything from Python to Firefox have the same problem, and
if they don't have the triplet in there somewhere then multiarch breaks
them.)
As long as the kernel can find the right ld.so and each ld.so can find
its own ld.so.conf, I don't really care where the libraries are put at
runtime, as long as I can make it different for each ISA/ABI. However,
I do care how much autoconf / pkg-config / debhelper misery I have to go
through each time I need to pull in another library dependency.
Upstream build machinery can usually accommodate
/just/about/anything/lib. Trailing components like lib32, libhf, or
lib-gnu-autoconf-triplet are not as consistently trivial.
Personally, I would like for all shared objects to live in
(/usr)?/gnu-autoconf-triplet(-extranoise)?/lib, and for the kernel to
take responsibility for pointing (/usr)?/lib at an overlay mount
containing whatever makes sense for the currently running binary, a la
/proc/self. That way I can grandfather in binaries with ABI-ignorant
hard-coded library paths, and still handle ISA variants. The
"extranoise" might be "neon", or "ssse3", or "android" (so that
non-Android binaries on the same system don't see Android-specific
libraries with stupidly generic names like libui.so). And the overlay
mount is so that I can, if I choose, build the vast majority of my
system without NEON instructions (and thus not take the overhead of VFP
context save/restore during timeslices that don't use actual floating
point) and still use a subset of those libraries from NEON-anointed
binaries (assuming I define some sensible way for the kernel to make
that distinction).
That isn't necessarily the right solution, of course -- either at a
technical level or in the light of the LSB process and other
inter-distro politics. But maybe it's at least a more plausible use
case for 2012 than NFS-mounting /usr/local on a mix of sun4c, sun4u, and
IRIX workstations. (That never did work quite right ...)
Cheers,
- Michael
