Hi, > >, since > > they have entirely different objectives
> Not entirely different - the objective for the packaging tools is > actually the same, to have packages install cleanly without changes on > systems with a different architecture triplet. I'm not sure this can be achieved at all, as we still need a root filesystem that isn't prefixed with the architecture triplet. The other issue is that generally, the 32/64 bit distinction does not necessarily mean that we use a different triplet. i386/amd64 does, at least in Debian, but that is optional as well and could be changed in the gcc package, which would give us a situation where only clearly incompatible arches need to be installed into a triplet directory. > >, 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). Simon -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
