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.
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 <[email protected]> at Wed, 11 May 2016 20:
* Disable testsuite.
-- Raspbian forward porter <[email protected]> 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.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments