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 Multi-Arch: allowed.

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.


1 Answer 1


This is mandated by the multiarch specification:

multiarch packages are required to be kept in lockstep; i.e., an implicit Breaks: ${self}:other (!= ${binary:Version}).

The reason is that packages always ship some arch-independent files in shared directories (/usr/share/doc), so the package management system has to ensure that they are identical across architectures. It does that by enforcing identical versions across architectures, even with binNMUs.

Inside a single distribution this isn’t much of a problem, but across distributions it is.

In your case specifically, let’s consider gcc-6-base (since that’s where the documentation lives). The Debian Stretch version installs its changelog in /usr/share/doc/gcc-6-base/changelog.Debian.gz. Installing the same package for other architectures, using the same version, installs the same file, so while technically there’s a conflict, it’s ignored. The Raspbian version however adds the following entry:

gcc-6 (6.3.0-18+rpi1+deb9u1) stretch-staging; urgency=medium

  [changes brought forward from 6.1.1-1+rpi1 by Peter Michael Green <plugwash@raspbian.org> at Wed, 11 May 2016 20:
  * Disable testsuite.

 -- Raspbian forward porter <root@raspbian.org>  Thu, 01 Mar 2018 00:03:02 +0000

Now the /usr/share/doc/gcc-6-base/changelog.Debian.gz is no longer identical. If we were to install both Debian Stretch and Raspbian Stretch versions of the package side-by-side, which version of the file should be kept? There’s no way to decide, so the packaging system forbids the situation entirely.

  • Awesome, super-thorough explanation all the way down to the changelog.Debian.gz diff in my test case packages.
    – jdonald
    Nov 16, 2018 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.