Bug#630853: cpp: multi-arch: foreign or multi-arch: allowed?
 

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

Bug#630853: cpp: multi-arch: foreign or multi-arch: allowed?
 

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DFF225B.5000303@debian.org">http://lists.debian.org/4DFF225B.5000303@debian.org

Bug#630853: cpp: multi-arch: foreign or multi-arch: allowed?
 

On Mon, Jun 20, 2011 at 12:35:07PM +0200, Matthias Klose wrote:

> > cpp's preprocessing behavior is architecture independent

> I don't think so. the predefined macros differ depending on the
> architecture / operating system.

Ok, true.

> > 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.

Alright. Then cpp should be Multi-Arch: allowed, and those reverse-depends
which don't care about architecture defines and includes can use the ':any'
syntax to depend on cpp.

> Is this only an issue with cpp, or with gcc too (holding headers and .o
> files) too?

I haven't yet encountered any cases where this matters for gcc, so I would
recommend only changing cpp for now.

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