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/`. 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 (-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/` 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//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/, /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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
