Skip to main content
Explain in more detail.
Source Link
Stephen Kitt
  • 480.9k
  • 59
  • 1.2k
  • 1.4k

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.

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.

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.

Source Link
Stephen Kitt
  • 480.9k
  • 59
  • 1.2k
  • 1.4k

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.