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 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? I believe we're safe from both. We're safe from the first because the only case I know of where cpp will be invoked as $target-cpp is when a package is being cross-built (either because it's actually being cross-built, or because of a mis-invocation of autoconf that sets things up for a cross-build instead of a native build). In that case, you almost certainly aren't going to get very far with cross-cpp, you need a cross-compiler as well; and if you have the cross-compiler correctly installed and configured, it will almost certainly come with (or depend on) cross-cpp, so no harm done. We're safe from the second because again, nobody uses cpp by itself as a toolchain that cares about system headers - they use it together with a compiler. And the compiler has this dependency graph: gcc ---Depends--> cpp | \ Depends Depends | \ V V gcc-4.x --Depends--> cpp-4.x So since none of the other packages in this graph are Multi-Arch: foreign, installing a foreign-arch cpp package would require installing foreign-arch versions of all the others - breaking any dependencies on gcc by a native-arch package. If you agree with the above reasoning, please make cpp Multi-Arch: foreign. If you see flaws in my reasoning, please make cpp Multi-Arch: allowed instead, and let me know what my error is. :) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature