With Raspbian and a 64-bit kernel, I am fetching packages from the following sources:
deb [arch=armhf] http://raspbian.raspberrypi.org/raspbian/ stretch main contrib non-free rpi deb http://deb.debian.org/debian stretch main contrib non-free deb http://deb.debian.org/debian stretch-updates main contrib non-free
Attempting to install the minimal dependencies to run something like gzip:arm64 reports conflicts such as:
libgcc1 : Breaks: libgcc1:arm64 (!= 1:6.3.0-18+rpi1+deb9u1) but 1:6.3.0-18+deb9u1 is to be installed gcc-6-base:arm64 : Breaks: gcc-6-base (!= 6.3.0-18+deb9u1) but 6.3.0-18+rpi1+deb9u1 is to be installed
It looks like the "+rpi1" armhf packages are conflicting with the non-rpi1 arm64 packages. But that would mean that it's comparing package versions across two different architectures!
Error messages with apt-get can be misleading anyhow, so to bring my system into a state similar to bamarni's Debian Pi64 (where multiarch works), I can try downloading some non-rpi1 armhf packages from links such as https://packages.debian.org/stretch/armhf/libgcc1/download Once I replace libgcc1:armhf, gcc-6-base:armhf, libc6:armhf, libatomic1:armhf and others, basic conflicts go away and I can install libgcc1:arm64 gcc-6-base:arm64 libc6:arm64 via apt. However, this isn't a great solution because in the process I have likely lost ARMv6 compatibility and other Raspbian-specific modifications.
And the above could still mean there's something else fishy hiding in the Raspbian packages. My next test is to use the Raspbian *.deb files, except with a script I repackage them to remove the
+rpi1 part of the version text in each control file. Once I do this and reinstall those packages, the conflicts with arm64 packages go away. This again indicates that APT is comparing package versions across two different architectures.
When I run
apt-cache show on any of these they all say
Multi-Arch: same with their correct corresponding
Architecture: lines. As I understand things, it would only care about versions across different architectures in the cases of
Multi-Arch: foreign or
What's going on here? It seems like APT is comparing package versions across different architectures when it shouldn't, which leads to bogus conflicts. I wonder if the fact that multiarch works okay on bamarni's Pi64 or Ubuntu MATE--or most i386+x86_64 systems--is in part luck that these systems have generally consistent package versions across 32-bit and 64-bit.