Criação de pacotes Debian: alvos de binary-arch e binary-indep

Question

Estou tentando criar meu primeiro deb, então ainda não sei muito sobre isso. Este é o meu arquivo 'rules' no momento:

#!/usr/bin/make -f
# Uncomment this to turn on verbose mode.
export DH_VERBOSE=1

# This has to be exported to make some magic below work.
export DH_OPTIONS

%:
        dh $@

No momento, estou lendo a documentação e tentando entender como escrever arquivos de regras mais complicados. Estou preso nos alvos 'binary-arch' e 'binary-indep'. Em suma, não entendo o que eles realmente representam.

A documentação diz que o pacote arch é determinado pela linha 'Architecture:' no arquivo 'Control'.

• Se o valor for 'all', o pacote é dependente da arquitetura.

• Se o valor for 'any', o pacote é uma arquitetura
  independente.

Eu compreendo perfeitamente essa parte. Mas então eu começo a ler arquivos de manual para ferramentas de debhelper.

man dpkg-buildpackage diz:

5. It calls debian/rules build followed by fakeroot debian/rules binary-target (unless a source-only build has been requested with -S). Note that binary-target is either binary (default case, or if -b is specified) or binary-arch (if -B is specified) or binary-indep (if -A is specified)

man dh diz:

Commands in the binary-indep sequence are passed the "-i" option to ensure they only work on binary independent packages, and commands in the binary-arch sequences are passed the "-a" option to ensure they only work on architecture dependent packages.

então eu tento ver o conjunto padrão de comandos para os alvos 'binary', 'binary-arch' e 'binary-indep' digitando

$ dh binary --no-act

$ dh binary-arch --no-act

$ dh binary-indep --no-act 

e obtenha conjuntos de comandos totalmente iguais. a única diferença é os sinalizadores '-i' e '-a' após cada comando.

Portanto, a primeira pergunta é - qual é a diferença entre, por exemplo, 'dh_auto_build', 'dh_auto_build -a' e 'dh_auto_build -i' (ou algum outro dh_command)?

E outra pergunta é - se o meu arquivo 'control' consiste apenas em pacotes com arquitetura 'all' eu preciso usar o target binário-indep, ou eu posso fazer sem ele e usar apenas o target build-arch nas minhas 'regras ' Arquivo ?

    

Answer 1

A diferença

O destino binary-indep cria todos os pacotes binários Architecture: all em seu pacote de código-fonte. O destino binary-arch cria todos os outros pacotes, Architecture: any ou pacotes com uma lista de arquitetura explícita ou alguns curingas de arquitetura como Architecture: linux-any .

Por quê?

A distinção destes dois caminhos dentro do processo de construção é relevante se você tiver um pacote fonte que contenha ambos os tipos de pacotes binários, dependentes de arquitetura e independentes: A compilação inicial do pacote constrói ambos os tipos de pacotes binários, mas cada construção subseqüente em arquiteturas diferentes precisa apenas construir os pacotes binários dependentes de arquitetura, já que você já construiu todos os pacotes independentes de arquitetura na primeira construção.

Exemplo

Imagine que você tenha um pacote fonte chamado foo , que cria os pacotes binários foo-programs e foo-data . Enquanto os programas em foo-programs precisam ser compilados (por exemplo, por serem escritos em C) e portanto o pacote binário é de Architecture: any , os arquivos de dados em foo-data (imagens, traduções, textos de ajuda, documentação, texturas, mapas de jogos, etc.) são os mesmos para todas as arquiteturas, por isso é Architecture: all . Digamos que a versão upstream do foo seja 1.0 e seja a primeira revisão do pacote Debian dessa versão upstream.

Você primeiro compila todos os pacotes na arquitetura amd64 para PCs de 64 bits, e você obterá foo-programs_1.0-1_amd64.deb e foo-data_1.0-1_all.deb . Mas você também quer poder executá-lo em PCs de 32 bits, portanto você também precisa de foo-programs_1.0-1_i386.deb . Mas você não precisa de um segundo foo-data_1.0-1_all.deb , portanto, seu processo de criação exige apenas as metas *-arch , por exemplo, chamando dpkg-buildpackage -B .

Necessidade de alvos explícitos

Com o mínimo dh style debian/rules pode não ser necessário especificar explicitamente os destinos, pois muitos sistemas de criação upstream não fazem essa distinção, mas se o fizerem (por exemplo, ter um destino make separado para a construção a documentação, você pode implementar isso, por exemplo, assim:

#!/usr/bin/make -f
%:
        dh $@

override_dh_auto_build-indep:
        $(MAKE) -C docs

(Exemplo retirado da página dh(7) man.)