apt makes wrong resolver choice when foreign arch repo included

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

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.

[@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…)

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