Hi,
I think that an alternative approach that should be given some consideration is what I
came up with for Exherbo. The differences from FHS are pretty small, and fits very easily
into autotools and CMake based packages as well. There is the original motivational write
up for this at:
https://exherbo.org/docs/multiarch.txt
To summarize the difference:
First, we accepted the /usr-merge (for simplicity and since most Linux distributions were
doing so) -- not doing so would require two parallel trees, but would not prohibit the
same approach. The next thing was to introduce a "namespace" within the
filesystem layout. The root became `/usr/<target>`. A few directories were exempt
from this (which is a trivial modification and could be ignored), namely /usr/share (for
shared, read-only, host-agnostic data). The toolchain was changed to be prefixed
(<target>-tool) as that simplified detection and folded into the autotools system
better. Because the usual prefix is `/usr/local`, and most linux distributions use `/usr`
for the distribution packages, most packages are already familiar with the idea of a
modified prefix. We use `/usr/<target>` as the prefix, and always use `lib` as the
library directory. At this point, all packages use the modified prefix, and are always
cross-compiled. There were a few packages that behaved badly f
or cross-compilation, but we have found most upstream developers accepting of patches for
fixing those issues and enabling cross-compilation in the process.
/usr/i686-unknown-linux-gnu/{bin,lib}
/usr/x86_64-unknown-linux-gnu/{bin,lib}
would allow the co-installation of 32-bit and 64-bit libraries without collision, as well
as tools as desired.
By having the prefix itself be modified, the debug information for the various builds also
is separated, and can be co-installed without issues (/usr/<target>/lib/debug/...).
One thing to note about this approach is that we replicate the header structure as well.
This is because some applications have target specific headers [1]. Having multiple
copies of the headers is not too expensive, and so it allows for a class of issues to be
entirely side stepped.
To demonstrate how well this actually fits into most of the GNU environment: this
effectively resulted in changing the value being passed to `--prefix` and `--datadir` for
autotools based packages. The rest was just a consequence of the setup and the
cross-compilation.
I think that it is useful to provide some examples of things which are enabled by such a
layout as it does diverge a bit from the traditional layout which can be a contentious
point. The idea allows for multiple (arbitrary) targets to be co-installed, with complete
images that would permit generation of a complete image (embedded or otherwise). This is
extremely helpful if you are trying to target an embedded system: you cross-compile the
full image, and then copy the subtree that matters for the target (/usr/<target>,
/usr/share, /var). This also works wonderfully if you are trying to do OS development:
you cross-compile and host a TFTP server which permits you to PXE boot the full image.
Another tweak would be a quick symlink adjustment (/usr/host) during boot from the
initramfs would permit a switch of the host ABI (for multi-ABI hosts, e.g. MIPS) given a
complete installation of multiple ABIs (it should be possible to co-install the full
spectrum of MIPS ABIs with this!).
Im happy to answer questions that you may have about issues that we ran into during the
migration or how to address any issues that may have been overlooked in our approach.
I'd like to point out that although the idea and initial prototype was my work, the
final implementation would not have been possible without the immense help that I received
from the rest of the developers on the Exherbo project.
[1]
https://src.fedoraproject.org/cgit/rpms/curl.git/tree/curl.spec#n197
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org