On 06/18/2011 04:13 AM, Steve Langasek wrote: > Package: cpp > Version: 4:4.6.0-6 > Severity: wishlist > Usertags: multiarch > > Hi there, > > The cpp metapackage has certain reverse-dependencies which, in the multiarch > world, need to be coinstallable (e.g., -dev packages like libregina3-dev and > xutils-dev). To support this, cpp needs to be tagged either Multi-Arch: > foreign, or Multi-Arch: allowed. > > Upon consideration, I think Multi-Arch: foreign is ok here. The interface > that cpp provides to its reverse-deps is always an exec() interface of > course, rather than a library interface, which normally would be enough to > qualify for Multi-Arch: foreign. But here there's also the factor that cpp > provides /usr/bin/$target-cpp, only for the given architecture. Could an > arch-dependent package that depends on cpp be assuming the availability of > /usr/bin/$target-cpp for its own arch? Or, coming from the other side,
> cpp's preprocessing behavior is architecture independent I don't think so. the predefined macros differ depending on the architecture / operating system. > but its header > search paths are not. Could accidentally installing a foreign arch version > of cpp break native packages that depend on it finding the native headers? why not, assuming that there is architecture dependent information in an architecture specific header? for the use of cpp to preprocess an series.in file (python2.7 package), I'm relying on the architecture pre-defines. Is this only an issue with cpp, or with gcc too (holding headers and .o files) too? Matthias -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dff225b.5000...@debian.org
