A versão do APT está em conflito com diferentes arquiteturas, mesmo com o Multi-Arch: mesmo?

Question

Com o Raspbian e um kernel de 64 bits, estou buscando pacotes das seguintes fontes:

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

Tentando instalar as dependências mínimas para executar algo como gzip: arm64 relata conflitos como:

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

Parece que os pacotes "+ rpi1" armhf estão em conflito com os pacotes não-rpi1 arm64 . Mas isso significaria que está comparando o pacote versões em duas arquiteturas diferentes!

Mensagens de erro com o apt-get podem ser enganosas de qualquer forma, então para trazer meu sistema para um estado semelhante ao Debian Pi64 do bamarni (onde o multiarch funciona), eu posso tentar baixar alguns pacotes armhf que não são rpi1 de links como link Uma vez que eu substitua libgcc1: armhf, gcc-6-base: armhf, libc6: armhf, libatomic1: armhf e outros , conflitos básicos vão embora e eu posso instalar o libgcc1: arm64 gcc-6-base: arm64 libc6: arm64 via apt. No entanto, esta não é uma ótima solução porque no processo eu provavelmente perdi a compatibilidade com o ARMv6 e outras modificações específicas do Raspbian.

E o acima ainda pode significar que há algo mais suspeito escondido nos pacotes Raspbian. Meu próximo teste é usar os arquivos .deb do Raspbian *, exceto que com um script eu os reembalei para remover a parte +rpi1 do texto da versão em cada arquivo de controle. Depois de fazer isso e reinstalar esses pacotes, os conflitos com pacotes arm64 desaparecem. Isso indica novamente que o APT está comparando as versões do pacote em duas arquiteturas diferentes.

Quando executo apt-cache show em qualquer um deles, todos dizem Multi-Arch: same com as linhas Architecture: corretas correspondentes. Pelo que entendi, ele só se preocuparia com versões de diferentes arquiteturas nos casos de Multi-Arch: foreign ou Multi-Arch: allowed .

O que está acontecendo aqui? Parece que o APT está comparando versões de pacotes entre diferentes arquiteturas quando não deveria, o que leva a conflitos falsos. Gostaria de saber se o fato de o multiarch funcionar bem no PiMa do bamarni ou no Ubuntu MATE - ou na maioria dos sistemas i386 + x86_64 - é em parte a sorte de esses sistemas terem versões de pacotes geralmente consistentes em 32 bits e 64 bits.

    

Answer 1

Isso é exigido pela especificação multiarch :

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

O motivo é que os pacotes sempre enviam alguns arquivos independentes de arco em diretórios compartilhados ( /usr/share/doc ), portanto, o sistema de gerenciamento de pacotes deve garantir que eles sejam idênticos entre as arquiteturas. Ele faz isso impondo versões idênticas entre as arquiteturas, mesmo com binNMUs.

Dentro de uma única distribuição, isso não é um grande problema, mas em todas as distribuições é.

Em seu caso especificamente, vamos considerar gcc-6-base (pois é onde a documentação mora). A versão do Debian Stretch instala seu changelog em /usr/share/doc/gcc-6-base/changelog.Debian.gz . Instalar o mesmo pacote para outras arquiteturas, usando a mesma versão, instala o mesmo arquivo. Por isso, embora haja um conflito tecnicamente, ele é ignorado. A versão Raspbian, no entanto, adiciona a seguinte entrada:

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

Agora, o /usr/share/doc/gcc-6-base/changelog.Debian.gz não é mais idêntico. Se nós instalássemos as versões Debian Stretch e Raspbian Stretch do pacote lado a lado, qual versão do arquivo deveria ser mantida? Não há como decidir, então o sistema de embalagem proíbe totalmente a situação.