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
A tentativa de 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 armhf "+rpi1" estão em conflito com os pacotes arm64 não-rpi1 . Mas isso significaria comparar versões de pacotes em duas arquiteturas diferentes!
Mensagens de erro com apt-get podem ser enganosas de qualquer forma, então para trazer meu sistema para um estado semelhante ao Debian Pi64 da bamarni (onde o multiarch funciona), posso tentar baixar alguns pacotes armhf não-rpi1 de links como https://packages. debian.org/stretch/armhf/libgcc1/download Depois de substituir libgcc1:armhf, gcc-6-base:armhf, libc6:armhf, libatomic1:armhf e outros, os conflitos básicos desaparecem e eu posso instalar libgcc1:arm64 gcc-6 -base:arm64 libc6:arm64 via apt. No entanto, essa não é uma ótima solução porque, no processo, provavelmente perdi a compatibilidade do ARMv6 e outras modificações específicas do Raspbian.
E o acima ainda pode significar que há algo mais suspeito escondido nos pacotes do Raspbian. Meu próximo teste é usar os arquivos Raspbian *.deb, exceto que com um script eu os reembalo para remover a +rpi1parte do texto da versão em cada arquivo de controle. Depois de fazer isso e reinstalar esses pacotes, os conflitos com os pacotes arm64 desaparecem. Isso indica novamente que o APT está comparando versões de pacotes em duas arquiteturas diferentes.
Quando eu corro apt-cache showem qualquer um deles, todos dizem com suas linhas Multi-Arch: samecorrespondentes corretas . Architecture:Pelo que entendi, só se preocuparia com versões em diferentes arquiteturas nos casos de Multi-Arch: foreignou Multi-Arch: allowed.
O que está acontecendo aqui? Parece que o APT está comparando versões de pacotes em diferentes arquiteturas quando não deveria, o que leva a conflitos falsos. Eu me pergunto se o fato de o multiarch funcionar bem no Pi64 da bamarni ou no Ubuntu MATE - ou na maioria dos sistemas i386 + x86_64 - é em parte sorte que esses sistemas tenham versões de pacotes geralmente consistentes em 32 bits e 64 bits.
Isso é exigido pela especificação multiarch :
A razão é que os pacotes sempre enviam alguns arquivos independentes de arch em diretórios compartilhados (
/usr/share/doc), portanto, o sistema de gerenciamento de pacotes deve garantir que eles sejam idênticos em todas as arquiteturas. Ele faz isso impondo versões idênticas em todas as arquiteturas, mesmo com binNMUs.Dentro de uma única distribuição isso não é um grande problema, mas em todas as distribuições é.
No seu caso especificamente, vamos considerar
gcc-6-base(já que é aí que a documentação fica). A versão 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, portanto, embora tecnicamente haja um conflito, ele é ignorado. A versão Raspbian, no entanto, adiciona a seguinte entrada:Agora o
/usr/share/doc/gcc-6-base/changelog.Debian.gznão é mais idêntico. Se 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.