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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
