Comment 4 for bug 1185896

Revision history for this message
David Kalnischkies (donkult) wrote :

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