APT version conflicts across different architectures even with Multi-Arch: same?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












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.










share|improve this question









New contributor




jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.























    up vote
    1
    down vote

    favorite












    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.










    share|improve this question









    New contributor




    jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      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.










      share|improve this question









      New contributor




      jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      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.







      debian apt dpkg multiarch arm64






      share|improve this question









      New contributor




      jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited yesterday





















      New contributor




      jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked yesterday









      jdonald

      1566




      1566




      New contributor




      jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      jdonald is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          2
          down vote



          accepted










          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.






          share|improve this answer






















          • Awesome, super-thorough explanation all the way down to the changelog.Debian.gz diff in my test case packages.
            – jdonald
            16 hours ago










          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );






          jdonald is a new contributor. Be nice, and check out our Code of Conduct.









           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f481824%2fapt-version-conflicts-across-different-architectures-even-with-multi-arch-same%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          2
          down vote



          accepted










          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.






          share|improve this answer






















          • Awesome, super-thorough explanation all the way down to the changelog.Debian.gz diff in my test case packages.
            – jdonald
            16 hours ago














          up vote
          2
          down vote



          accepted










          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.






          share|improve this answer






















          • Awesome, super-thorough explanation all the way down to the changelog.Debian.gz diff in my test case packages.
            – jdonald
            16 hours ago












          up vote
          2
          down vote



          accepted







          up vote
          2
          down vote



          accepted






          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.






          share|improve this answer














          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited yesterday

























          answered yesterday









          Stephen Kitt

          156k23343416




          156k23343416











          • Awesome, super-thorough explanation all the way down to the changelog.Debian.gz diff in my test case packages.
            – jdonald
            16 hours ago
















          • Awesome, super-thorough explanation all the way down to the changelog.Debian.gz diff in my test case packages.
            – jdonald
            16 hours ago















          Awesome, super-thorough explanation all the way down to the changelog.Debian.gz diff in my test case packages.
          – jdonald
          16 hours ago




          Awesome, super-thorough explanation all the way down to the changelog.Debian.gz diff in my test case packages.
          – jdonald
          16 hours ago










          jdonald is a new contributor. Be nice, and check out our Code of Conduct.









           

          draft saved


          draft discarded


















          jdonald is a new contributor. Be nice, and check out our Code of Conduct.












          jdonald is a new contributor. Be nice, and check out our Code of Conduct.











          jdonald is a new contributor. Be nice, and check out our Code of Conduct.













           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f481824%2fapt-version-conflicts-across-different-architectures-even-with-multi-arch-same%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown






          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Displaying single band from multi-band raster using QGIS

          How many registers does an x86_64 CPU actually have?