apt makes wrong resolver choice when foreign arch repo included

[Wookey]

In a fresh raring chroot adding foreign-arch armhf then apt-get installing crossbuild-essential-armhf works fine.
But if a repo arch-qualified for another arch (arm64) is added, and apt-get update run, installing crossbuild-essential-armhf now fails.

The reason for this is not clear. Here is a summary of what I've found so far.
apt-get install crossbuild-essential-armhf
  crossbuild-essential-armhf : Depends: dpkg-cross but it is not going to be installed
apt-get install dpkg-cross
  dpkg-cross : Depends: libdebian-dpkgcross-perl (= 2.6.9ubuntu2) but it is not going to be installed
apt-get install libdebian-dpkgcross-perl
  works, but tries to remove: libidn11 libssl1.0.0 libudev0 multiarch-support wget
(and replace multiarch-support:amd64 with multiarch-support:armhf, which breaks things)

doing apt-get install crossbuild-essential-armhf libdebian-dpkgcross-perl multiarch-support:amd64 gets apt to do the right thing.

So the question is why is apt prefering the solution of not installing crossbuild-essential-armhf over the correct solution of installing crossbuild-essential-armhf libdebian-dpkgcross-perl multiarch-support:amd64

I did
apt-get -oDebug::pkgProblemResolver=1 install crossbuild-essential-armhf
and got the attached apt-debug file

I've also attached a script log of the session demonstrating that crossbuild-essential-armhf installs as expected unti l the extra arm64 repo is made available

I think this can be reproduced by doing
sbuild-createchroot for raring on amd64 box
adding this repo to apt config:
deb [arch=arm64] http://people.debian.org/~wookey/bootstrap/ubunturepo/ raring-bootstrap main universe
deb-src http://people.debian.org/~wookey/bootstrap/ubunturepo/ raring-bootstrap main universe

and doing the above tests, as documented in the script log attached

the problem seems to revolve around apt starting by considering multiarch-support:arm64

[Wookey (wookey)]

script log of session demonstarting that it works until the arm64 repo is added, then it doesn't until multiarch-support:amd64 is explicitly specified

[Wookey (wookey)]

It's unclear to me exactly what's going wrong here, but the fact that multiarch-support:arm64 is being considered by the resolver seems wrong, when the native arch is amd64 and the foreign arch is armhf. Should it not be filtered out?

Should this package even appear in the apt cache? (maybe that is OK - the package file was downloaded)

This simpler command also makes apt install the correct things:
apt-get install crossbuild-essential-armhf multiarch-support

attached is the debug output from running that in case it helps.

[David Kalnischkies (donkult)]

[@wookey: Your last attachment is the same as the first one – I at least see nothing working in it ;) ]

mhh, I had a little stare-down contest with the resolver in the train now and it looks like the resolver is trying to satisfy the dependencies of crossbuild-essential-armhf via arm64 indicated by trying to install file:arm64 for libdebian-dpkgcross-perl:all.
Couldn't reproduce it in a selfbuilt testcase myself though, so I will try it later with a reliable internet connection.

The other interesting bit is that multiarch-support:arm64 isn't "providing" multiarch-support:amd64, which is actually kinda nice, but the reverse that :amd64 isn't providing :arm64 is wrong (as we don't have a distinction between "known to dpkg/configured in APT::Architectures" and "included in the cache via sources.list [arch=]" both is wrong).

Which leads me to wonder if multiarch-support is actually correct in being M-A:foreign. Given that it is supposed to ensure that the libc6 used is new enough it feels strange that at least in theory on i386 system I could install multiarch-support:armel and make the dependencies happy while the ld.so I am using is potentially still not new enough.
(A bit late/academic to wonder about that now, but yeah…)

[Steve Langasek (vorlon)]

> Which leads me to wonder if multiarch-support is actually correct in being M-A:foreign.

It is, though the reason isn't altogether obvious. The reason it was made M-A: foreign was to break what was otherwise a dependency loop for adding foreign architectures: libc6 Depends: libgcc1 Pre-Depends: multiarch-support Depends: libc6. Since the whole purpose of multiarch-support was to ensure that libraries for your primary arch were not disappeared out from underneath the linker during the transition to multiarch, we don't care about multiarch-support for any except the primary architecture... you can't possibly install the foreign-arch multiarch-support package *before* transitioning to multiarch, and if you do it *afterwards* it no longer matters.

Indeed, now that the transition is complete (since wheezy has released with multiarch-support), we could update debhelper to no longer add the multiarch-support Pre-Depends in unstable.