Hello, >>> , and there is generally no need to >>> install anything but libraries and headers into /usr/<triplet> -- so I >>> don't think there is a pressing need to replicate a filesystem hierarchy >>> standard below a triplet directory. > >> True, however, that is not a sufficient reason to not >> move /usr/<triplet> to /usr/lib/<triplet> and /usr/include/<triplet> >> if it means getting such support into the core Debian packaging tools. > > Indeed, however this makes building stuff without the packaging tools a lot > harder -- for example I need to patch gcc to recognize these paths if I > build gcc by hand. It might be a lot easier to have the packaging tools > handle the "current" layout than to patch all the software that assumes > that software is generally installed into "include" and "lib" dirs under a > common prefix (such as most GNU software that uses the autoconf macros to > find installed software).
That's totally right and that is my point, I really think multiarch is not well designed to fit into cross compiling. They (dpkg-core) might want us to do extra work which will break our stuff. And as from the point of view of multiarch we probably have a nice, simple and working solution right now, without even notice it. The only reason I found against our approach is: " Why not prefix/arch-os/lib/ (and include/)? It would pollute the prefix directory. Can you imagine adding one entry for each target to the root and /usr directories? Better that they go under the prefix/lib/ (and include/) directories which already contain many files. " Which in practice it is not so bad to do all the extra work that multiarch needs to get done. Please correct me if I am wrong -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
