Como convencer o APT de que um pacote de arco cruzado é instalado manualmente?

Question

Eu tenho um ambiente chroot qemu-armhf em uma máquina amd64 (é principalmente para compilar o código Raspberry Pi). Como tal, ele pode executar os binários armhf e amd64, mas é mais rápido fazer o último.

Existem certos pacotes (como make) onde instalei a versão amd64 dentro do chroot para obter uma velocidade melhor. Isso funciona bem até que eu preciso do apt-get algum outro pacote armhf e acontece de ter o make listado como uma dependência, quando eu recebo isso:

The following packages have unmet dependencies:
 build-essential : Depends: make but it is not going to be installed
 dpkg-dev : Depends: make but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

Se eu tentar o comando sugerido, ele diz que deseja instalar make:armhf e desinstalar make:amd64 . Eu não quero fazer isso. Como eu digo ao APT que make:armhf já está instalado (porque eu quero usar make:amd64 para satisfazer dependências) sem realmente instalá-lo?

Eu tentei usar apt-mark manual make , mas ele diz que não está instalado.

Eu sei que este provavelmente não é o jeito certo de fazê-lo, mas eu estive olhando o arquivo /var/lib/dpkg/status para tentar descobrir como ele acha que as definições de pacote funcionam e tentar enganá-lo e concordar que make: amd64 satisfaz make: armhf também.

Em particular, notei que "libbz2-1.0" é um pacote listado como instalado duas vezes; uma vez como:

Architecture: armhf
Multi-Arch: same
Pre-Depends: multiarch-support

e uma vez como:

Architecture: amd64
Multi-Arch: foreign
Pre-Depends: multiarch-support

Então eu tentei duplicar as entradas para "make" da mesma forma, definindo todos esses valores acima. Mas agora o APT está apenas dizendo que "make" e "make: amd64" estão em conflito. Por que é um conflito quando o make faz isso, mas não quando o libbz2-1.0 faz isso? (Espero que não sejam bibliotecas de invólucros especiais; isso parece ser um bug.)

Por esta resposta , tentei criar um pacote fictício com equivs e instalá-lo (após remover meu manual mexendo acima), mas instalá-lo produz esses erros:

# dpkg -i /var/cache/apt/archives/make_3.81-8.2_amd64.deb (real amd64 make)
# dpkg -i make_3.81-8.2_armhf.deb (fake armhf depends on the above)
Preparing to replace make 3.81-8.2 (using make_3.81-8.2_armhf.deb) ...
Unpacking replacement make ...
dpkg: dependency problems prevent configuration of make:
 make depends on make:amd64 (= 3.81-8.2).

Então, novamente, o problema parece que o make: armhf é um substituto para o make: amd64, e eu não sei como dizer que eu quero que esses dois pacotes coexistam. (Não parece ter um problema com a idéia de dois pacotes libbz2 coexistindo, por exemplo).

    

Answer 1

Eu não joguei muito com sistemas multiarch, então pode haver uma maneira melhor do que eu estou propondo aqui. Eu não testei minha proposta, não tenho certeza se isso não é uma peculiaridade do multiarch.

Você pode usar equivs para criar um manequim pacotes apenas para dependências.

1. Crie um arquivo de controle com equivs-control make.control
2. Edite o arquivo de controle: defina Package: make , Architecture: armhf , Depends: make:amd64 e Multi-Arch: foreign . Você pode querer definir Version para combinar com a versão amd64 make também.
3. Crie o pacote fictício: equivs-build make.control
4. Instale o pacote fictício no chroot

Se isto não satisfizer o dpkg, uma abordagem diferente que funcionará, mas é menos conveniente, é não instalar o amd64 make dentro do chroot, mas tornar a raiz do host disponível dentro do chroot (com uma montagem bind, veja < href="https://unix.stackexchange.com/questions/4897/providing-bin-and-lib-inside-a-chroot-jail"> Fornecendo / bin e / lib dentro de uma jaula chroot exemplos), ou pelo menos o make binário e suas dependências (que para make é apenas libc). Adicione o diretório onde o binário está montado no PATH. Crie um pacote fictício como acima, mas apenas declare make como instalado, não coloque nenhum cabeçalho Depends ou Multi-Arch .