Ubuntu Manpage: debhelper - a suite de ferramentas debhelper

NOME

       debhelper - a suite de ferramentas debhelper

RESUMO

       dh_* [-v] [-a] [-i] [--no-act] [-ppackage] [-Npackage] [-Ptmpdir]

DESCRIÇÃO

Debhelper é usado para ajudá-lo a compilar um pacote Debian. A filosofia por detrás de debhelper é
disponibilizar uma colecção de ferramentas pequenas, simples e de fácil compreensão que são usadas em
debian/rules para automatizar vários aspectos comuns da compilação de um pacote. Isto significa menos
trabalho para si, o empacotador. Também significa, até certo ponto, que estas ferramentas podem ser
alteradas se a política de Debian alterar, e os pacotes que as usam irão precisar apenas de uma
recompilação para ficarem em conformidade com a nova política.

Um ficheiro debian/rules típico que usa debhelper irá chamar vários comandos debhelper em sequência, ou
usar dh(1) para automatizar este processo. Em /usr/share/doc/debhelper/examples/ estão exemplos de
ficheiros de regras que usam debhelper.

Para criar um novo pacote Debian usando o debhelper, você pode copiar um dos ficheiros de regras exemplo
e editá-lo à mão. Ou pode tentar o pacote dh-make, o qual contém um comando dh_make que automatiza
parcialmente o processo Para uma introdução mais gentil, o pacote Debian maint-guide contém um tutorial
acerca de como fazer o seu primeiro pacote usando o debhelper.

Excepto onde a ferramenta explicitamente denota, caso contrário, todas as ferramentas do debhelper
assumem que são corridas a partir do directório raiz de um pacote fonte descompactado. Isto é feito para
que possam localizar e encontrar ficheiros como debian/control quando necessário.

COMANDOS DO DEBHELPER

       Aqui está a lista dos comandos debhelper que você pode usar. Veja os seus manuais para documentação
       adicional.

           #LISTA#

   Comandos Descontinuados
       Alguns comandos debhelper estão descontinuados e não devem ser usados.

           #LISTA_DE_DESCONTINUADOS#

   Outros comandos
       Se o nome dum programa começa com dh_, e o programa não está nas listas em cima, então não faz parte do
       pacote debhelper, mas mesmo assim deverá funcionar como os outros programas descritos nesta página.

FICHEIROS DE CONFIGURAÇÃO DO DEBHELPER

Muitos comandos do debhelper usam ficheiros em debian/ para controlar o que fazem. Para além dos comuns
debian/changelog e debian/control, que estão em todos os pacotes, e não apenas aqueles que usam
debhelper, alguns ficheiros adicionais podem ser usados para configurar o comportamento de comandos
debhelper específicos. Estes ficheiros são chamados tipicamente debian/pacote.foo (onde pacote é claro, é
substituído pelo nome do pacote no qual se está a actuar).

Por exemplo, dh_installdocs usa ficheiros chamados debian/package.docs para listar os ficheiros de
documentação que ira instalar. Veja os manuais individuais dos comandos para detalhes acerca dos nomes e
formatos dos ficheiros que usam. Geralmente, estes ficheiros irão listar ficheiros onde se vai actuar, um
ficheiro por linha. Alguns programas no debhelper usam pares de ficheiros e destinos ou formatos
ligeiramente mais complicados.

Nota para o primeiro (ou único) pacote binário listado em debian/control, o debhelper irá usar debian/foo
quando não existe nenhum ficheiro debian/package.foo. No entanto, é geralmente uma boa ideia manter o
prefixo package. pois é mais explícito. A principal excepção a isto são ficheiro que o debhelper instala
por predefinição em todos os pacotes binários quando não tem um prefixo de pacote (tal como
debian/copyright ou debian/changelog).

Em alguns casos raros, você pode querer ter versões diferentes destes ficheiros para arquitecturas ou
sistemas operativos diferentes. Se existirem ficheiros chamados debian/pacote.foo.ARCH ou
debian/pacote.foo.OS, onde ARCH e OS são o mesmo que o resultado de "dpkg-architecture -qDEB_HOST_ARCH" /
"dpkg-architecture -qDEB_HOST_ARCH_OS", então eles irão ser usados em preferência de outros ficheiros
mais gerais.

Maioritariamente, estes ficheiros de configuração são usados para especificar listas de vários tipos de
ficheiros. Documentação ou ficheiros exemplo para instalar, ficheiros para mover, e etc. Quando
apropriado, em casos como estes, você pode usar caracteres "wildcard" de shell standard (classes de
caracteres ? e * e [..]) nos ficheiros. Também pode meter comentários neste ficheiros; as linhas
começadas com # são ignoradas.

A sintaxe destes ficheiros é mantida intencionalmente muito simples para os tornar fáceis de ler,
compreender e modificar.

Substituições em ficheiros de configuração do debhelper
Em nível de compatibilidade 13 e posterior, é possível usar substituições simples em ficheiros de
configuração do debhelper para as seguintes ferramentas:

• dh_clean

• dh_install

• dh_installcatalogs

• dh_installdeb

• dh_installdirs

• dh_installdocs

• dh_installexamples

• dh_installinfo

• dh_installman

• dh_installwm

• dh_link

• dh_missing

• dh_ucf

Todas as variáveis de substituição são do formato ${foo} e as chavetas são obrigatórias. Os nomes das
variáveis são sensíveis a maiúscula/minúscula e consistem de alfanuméricos (a-zA-Z0-9), hífens (-),
underscores (_), and dois pontos (:). O primeiro caractere tem de ser alfanumérico.

Se precisar de um sinal literal de dollar que não despolete uma substituição, você pode ou usar a
substituição de ${Dollar} ou a sequência ${}.

As seguintes expansões estão disponíveis:

DEB_HOST_*, DEB_BUILD_*, DEB_TARGET_*
Expande para o valor dpkg-architecture(1) relevante (semelhante a dpkg-architecture -qVARIABLE_HERE).

Em caso de dúvida, a variante DEB_HOST_* é aquela que irá trabalhar para ambas compilações nativas e
cruzadas.

Por razões de performance, o debhelper irá tentar resolver esses nomes primeiro a partir do ambiente
antes de consultar dpkg-architecture(1). Isto é muito mencionado para plenitude pois não irá ter
importância na maioria dos casos.

Dollar
Expande para um símbolo literal único $-symbol. Este símbolo nunca irá ser considerado parte de uma
variável de substituição. Isso é:

# Triggers an error
${NO_SUCH_TOKEN}
# Expands to the literal value "${NO_SUCH_TOKEN}"
${Dollar}{NO_SUCH_TOKEN}

Esta variável é equivalente à sequência ${} e as duas podem ser usadas alternadamente.

Newline, Space, Tab
Expande para uma nova linha ASCII única, espaço e tab respetivamente.

Isto pode ser útil se precisar de incluir um caractere literal de "espaço em branco" (ex. espaço)
onde caso contrário ele iria ser descartado ou usado como um separador.

env:NAME
Expande para a variável de ambiente NAME. A variável de ambiente tem de estar definida (mas pode
estar definida para uma string vazia).

Note que todas as variáveis têm de expandir para um valor definido. Como exemplo, se o debhelper vir
${env:FOO}, então ele irá insistir que a variável de ambiente FOO está definida (pode estar definida para
uma string vazia).

Limites de substituição

Para evitar ciclos infinitos e exaustão de recursos, o debhelper irá parar com um erro se o texto conter
muitas variáveis de substituição (50) ou se elas expandirem para lá de um determinado tamanho (4096
caracteres ou 3x o comprimento da entrada original - qual deles for maior).

Ficheiros de configuração do debhelper executáveis.
Se precisar de flexibilidade adicional, muitas das ferramentas debhelper (ex, dh_install(1)) suportam
executar um ficheiro de configuração como um script.

Para usar esta funcionalidade, simplesmente marque o ficheiro de configuração como executável (ex. chmod
+x debian/package.install) e a ferramenta irá tentar executá-lo e usar o resultado do script. Em muitos
casos, você pode usar dh-exec(1) como interpretador do ficheiro de configuração para reter a maioria da
sintaxe original enquanto obtém a flexibilidade adicional que precisa.

Quando usar ficheiros de configuração executáveis do debhelper, por favor tenha em atenção o seguinte:

• O ficheiro de configuração executável must termina com sucesso (isto é, o seu código de retorne deve
indicar sucesso).

• Em nível de compatibilidade 13+, o resultado será sujeito a substituições (veja "Substituições em
ficheiros de configuração do debhelper") onde a ferramenta suportar estes. Lembre-se disto se o seu
gerador também disponibilizar substituições pois isto pode causar confusão desnecessária.

Caso contrário, o resultado de saída irá ser usado exatamente como está. De notar que o debhelper não
irá expandir wildcards, nem retirar comentários ou espaços em branco ao resultado de saída.

Se precisar que o pacote compile num sistema de ficheiros onde não pode desactivar o bit de executável,
então você pode usar dh-exec(1) o o seu script strip-output.

OPÇÕES DO DEBHELPER PARTILHADAS

As seguintes opções de linha de comandos são suportadas por todos os programas do debhelper.

-v, --verbose
Modo detalhado: mostra todos os comandos que modificam o directório de compilação de pacotes.

--no-act
Não faz nada na realidade. Se usado com -v, o resultado é que o comando mostra o que iria fazer.

-a, --arch
Actua em pacotes dependentes da arquitectura que devem ser compilados para a arquitectura de
compilação DEB_HOST_ARCH.

-i, --indep
Actua em todos os pacotes independentes da arquitectura.

-ppacote, --package=pacote
Actua no pacote chamado pacote. Esta opção pode ser especifica várias vezes para fazer o debhelper
operar num determinado conjunto de pacotes.

-s, --same-arch
Alias descontinuado de -a.

Esta opção foi removida no nível de compatibilidade 12.

-Npacote, --no-package=pacote
Não actua no pacote especificado mesmo se uma opção -a, -i, ou -p listarem o pacote como um em que se
deverá actuar.

--remaining-packages
Não actua nos pacotes que já foram actuados antes por este comando do debhelper (isto é, se o comando
estiver presente no debhelper log do pacote). Por exemplo, se você precisar de chamar o comando com
opções especiais apenas para um par de pacotes binários, passe esta opção para a última chamada do
comando para processar o resto dos pacotes com as definições predefinidas.

-Ptmpdir, --tmpdir=tmpdir
Usa tmpdir para directório de compilação de pacotes. A predefinição é debian/pacote

--mainpackage=pacote
Esta opção pouco usada muda o pacote que o debhelper considera o "pacote principal", isto é, o
primeiro listado em debian/control, e aquele para o qual os ficheiros debian/foo podem ser usados em
vez dos ficheiros debian/package.foo usuais.

-O=opção|bundle
Isto é usado pelo dh(1) quando se passa opções específicas do utilizador a todos os comandos que
corre. Se o comando suportar a opção ou opções especificadas, irá fazer efeito. Se o comando não
suportar a opção (ou alguma parte do conjunto de opções), será ignorado.

OPÇÕES COMUNS DO DEBHELPER

       As  seguintes opções de linha de comandos são suportadas por alguns programas do debhelper. Veja o manual
       de cada programa para uma explicação completa sobre o que cada opção faz.

       -n  Não modifique os scripts postinst, postrm, etc.

       -Xitem, --exclude=item
           Exclui um item do processamento. Esta opção pode ser usada várias vezes, para excluir mais do que uma
           coisa. O item é tipicamente parte de um nome de ficheiro, e qualquer ficheiro que  contenha  o  texto
           especificado será excluído.

       -A, --all
           Faz  com  que  ficheiros  ou outros itens que são especificados na linha de comandos tenham efeito em
           TODOS os pacotes em que se actua, e não apenas o primeiro.

OPÇÕES DO SISTEMA DE COMPILAÇÃO

As seguintes opções de linha de comandos são suportadas por todos os comandos dh_auto_* do debhelper.
Estes programas suportam uma variedade de sistemas de compilação, e normalmente determinam
heuristicamente qual usar, e como os usar. Você pode usar estes opções de linha de comandos para sobrepor
o comportamento predefinido. Tipicamente estas são passadas ao dh(1), o qual passa-as a todos os
programas dh_auto_*.

-Sbuildsystem, --buildsystem=buildsystem
Força a utilização do |<buildsystem> especificado, em vez de tentar auto-seleccionar um que pode ser
aplicável para o pacote.

Passa none como buildsystem para desactivar a auto-selecção.

-Ddirectory, --sourcedir=directory, --sourcedirectory=directory
Assume que a árvore fonte do pacote original está no directório especificado em vez de estar no
directório de nível de topo da árvore de pacotes fonte de Debian.

Aviso: A variante --sourcedir corresponde a uma opção de nome semelhante em dh_install e dh_missing
(etc.) por razões históricas. Apesar de terem nomes semelhantes, elas têm objectivos muito distintos
e em alguns casos podem causar erros quando esta variante é passada ao dh (quando então passada para
todas as ferramentas).

-B[directory], --builddir[=directory], --builddirectory[=directory]
Activa a compilação da fonte e usa o directório especificado como o directório de compilação. Se o
parâmetro directório for omitido, é escolhido o directório de compilação predefinido.

Se esta opção não for especificada, a compilação será feita por predefinição na fonte a menos que o
sistema de compilação requeira ou prefira a compilação da árvore de fonte. Em tal caso, será usado o
directório de compilação predefinido mesmo se --builddirectory não seja especificado.

Se o sistema de compilação preferir a compilação da árvore fonte mas ainda permitir a compilação da
fonte, a última pode ser re-activada ao passar-lhe um caminho para um directório de compilação que é
o mesmo que o caminho para o directório fonte.

--parallel, --no-parallel
Controla se devem ser usadas compilações paralelas se o sistema de compilação o suportar. O número de
trabalhos paralelos é controlado pela variável de ambiente DEB_BUILD_OPTIONS ("Debian Policy, secção
4.9.1") durante a compilação. Também pode servir como um limite específico do sistema de compilação.

Se nenhuma destas opções for especificada, presentemente o debhelper usa por predefinição --parallel
em modo compatibilidade 10 (ou posterior) e --no-parallel em caso contrário.

Como uma optimização, o dh irá tentar evitar passar estas opções aos sub-processos, se estas forem
desnecessárias e as únicas opções a passar. De notar que isto acontece quando DEB_BUILD_OPTIONS não
tem um parâmetro parallel (ou o seu valor é 1).

--max-parallel=máximo
Esta opção implica --parallel e permite mais limitação ao número de trabalhos que podem ser usados
numa compilação paralela. Se a compilação do pacote é conhecida por apenas funcionar em certos níveis
de concorrência, você pode definir isto para o nível máximo que é sabido funcionar, ou que deseje
suportar.

De notar que, definir o máximo para 1 é efectivamente o mesmo que usar --no-parallel.

--reload-all-buildenv-variables
Por predefinição, o dh(1) irá computar vários ambientes (ex. ao usar dpkg-buildflags(1)) e guarda-los
em cache para evitar que todas as ferramentas dh_auto_* os recompute.

Quando se passa esta opção, a ferramenta dh_auto_* concreta irá ignorar a cache de dh(1) e re-
despoletar uma recompilação destas variáveis. Isto é útil nos casos muito raros onde o pacote precisa
de fazer múltiplas compilações mas com diferentes opções ...FLAGS. Um exemplo concreto seria precisar
de alterar o parâmetro -O em CFLAGS na segunda compilação:

export DEB_CFLAGS_MAINT_APPEND=-O3

%:
dh $@

override_dh_auto_configure:
dh_auto_configure -Bbuild-deb ...
DEB_CFLAGS_MAINT_APPEND=-Os dh_auto_configure \
--reload-all-buildenv-variables -Bbuild-udeb ...

Sem --reload-all-buildenv-variables na segunda chamada ao dh_auto_configure(1), a alteração em
DEB_CFLAGS_MAINT_APPEND seria ignorada pois dh_auto_configure(1) iria usar o valor em cache de
<CFLAGS> definido por dh(1).

Esta opção está apenas disponível com debhelper (>= 12.7~) quando o pacote usar nível de
compatibilidade 9 ou posterior.

--list, -l
Lista todos os sistemas de compilação suportados pelo debhelper neste sistema. A lista inclui ambos
sistemas de compilação predefinidos e de terceiros (marcados como tal). Também mostra qual o sistema
de compilação será seleccionado automaticamente, ou qual está especificado manualmente com a opção
--buildsystem.

NÍVEIS DE COMPATIBILIDADE

De tempos a tempos, precisam de ser feitas grandes alterações no debhelper que não compatíveis com as
versões anteriores, para o manter limpo e bem construído quando as necessidades alteram e o seu autor
ganha mais experiência. Para prevenir que tais grandes alterações danifiquem os pacotes existentes, foi
introduzido o conceito de níveis de compatibilidade no debhelper. Você deve dizer ao debhelper qual o
nível de compatibilidade que ele deve usar, e ele modifica o seu comportamento de várias maneiras.

No debhelper actual, você pode especificar o nível de compatibilidade em debian/control ao adicionar um
Build-Depends no pacote debhelper-compat. Por exemplo, para usar modo v13, assegure que debian/control
tem:

Build-Depends: debhelper-compat (= 13)

Isto também serve como uma dependência de compilação de versão apropriada numa versão suficiente do
pacote debhelper, assim você não precisa de especificar uma dependência de compilação de versão separada
no pacote debhelper a menos que precise de um lançamento pontual específico do debhelper (tal como para a
introdução de uma nova funcionalidade ou correcção de bug dentro de um nível de compatibilidade).

Note que o debhelper não fornece debhelper-compat para os níveis de compatibilidade experimental ou beta;
os pacotes que experimentem com esses níveis de compatibilidade devem usar debian/compat ou DH_COMPAT.

As versões anteriores do debhelper requeriam o nível de compatibilidade especificado no ficheiro
debian/compat, e o debhelper actual ainda suporta isto para compatibilidade com as versões anteriores,
apesar de um pacote não poder especificar um nível de compatibilidade via múltiplos métodos de uma vez.
Para usar este método, debian/compat deve conter o nível de compatibilidade como um número singular, e
nenhum outro conteúdo. Se você especificar o nível de compatibilidade neste método, o seu pacote vai
também precisar duma dependência de compilação baseada em versão de uma versão do pacote debhelper igual
(ou superior) ao nível de compatibilidade que o seu pacote usa. Assim, se você especificar o nível de
compatibilidade 13 em debian/compat, assegure-se que debian/control tem:

Build-Depends: debhelper (>= 13~)

A menos que seja indicado o contrário, toda a documentação do debhelper assume que você está a usar o
nível de compatibilidade mais recente, e na maioria dos casos não indica se o comportamento é diferente
num nível de compatibilidade anterior, portanto se não está a usar o nível de compatibilidade mais
recente, você é aconselhado a procurar em baixo por notas acerca do que é diferente nos níveis de
compatibilidade anteriores.

Níveis de compatibilidade suportados
Estes são os níveis de compatibilidade disponíveis:

v7 Este modo está descontinuado.

Este é o nível de compatibilidade mais baixo suportado.

Se você está a actualizar a partir de um nível de compatibilidade anterior, por favor reveja
debhelper-obsolete-compat(7).

v8 As alterações a partir de v7 são:

- Os comandos irão falhar em vez de emitirem avisos quando lhes são passadas opções
desconhecidas.

- dh_makeshlibs irá correr dpkg-gensymbols em todas as bibliotecas partilhadas para as quais
gera ficheiros shlibs. Portanto o -X pode ser usado para excluir bibliotecas. Também, as
bibliotecas em localizações fora do habitual que o dpkg-gensymbols não tenha processado antes
serão passadas para ele, uma alteração no comportamento que pode causar que alguns pacotes
falhem a compilar.

- dh requer que a sequência a correr seja especificada como o primeiro parâmetro, e quaisquer
switches que venham depois dela. Isto é, use dh $@ --foo", e não "dh --foo $@

- dh_auto_* prefere usar o Module::Build do Perl em preferência de Makefile.PL.

Este modo está descontinuado.

v9 As alterações a partir de v8 são:

- Suporte a multi-arquitectura. Em particular, dh_auto_configure passa directórios de multi-
arquitectura ao autoconf em --libdir e --libexecdir.

- O dh tem conhecimento das dependências habituais entre alvos em debian/rules. Por isso, o "dh
binary" irá correr quaisquer alvos de build, build-arch, build-indep, install, etc que
existam no ficheiro de regras. Não há necessidade de definir um alvo binário explícito com
dependências explícitas em outros alvos.

- dh_strip comprime ficheiros de símbolos de depuração para reduzir o tamanho instalado dos
pacotes -dbg.

- dh_auto_configure não inclui o nome do pacote fonte em --libexecdir quando usa autoconf.

- dh não tem por predefinição a activação de --with=python-support

(Obsoleto: Pois a ferramenta dh_pysupport foi removida a partir de Debian stretch. Desde o
debhelper/10.3, dh já não se activa esta sequência add-on independentemente do nível de
compatibilidade)

- Todos os programas debhelper dh_auto_* e dh definem variáveis de ambiente listadas por dpkg-
buildflags, a menos que elas estejam já definidas.

- dh_auto_configure passa as dpkg-buildflags CFLAGS, CPPFLAGS, e LDFLAGS para Makefile.PL e
Build.PL de perl.

- dh_strip põe símbolos de depuração separados numa localização baseada no seu build-id.

- Os ficheiros de configuração executáveis do debhelper são corridos e os seus resultados
usados como configuração.

Este modo está descontinuado.

v10 As alterações a partir de v9 são:

- dh_installinit não irá mais instalar um ficheiro chamado debian/pacote como um script de
iniciação (init).

- O dh_installdocs irá dar erro se detectar links criados com --link-doc entre pacotes de
arquitectura "all" e não-"all" porque isso faz quebrar binNMUs.

- O dh_installdeb já não instala um ficheiro debian/pacote.shlibs disponibilizado pelo
maintainer. Em vez disso, isto agora é feito pelo dh_makeshlibs.

- O dh_installwm recusa-se a criar um pacote quebrado se não encontrar nenhuma página de manual
(necessário para registo para a alternativa do x-window-manager).

- Debhelper irá predefinir para --parallel em todos os sistemas de compilação que suportam
compilação paralela. Isto pode ser desactivado usando --no-parallel ou passando
--max-parallel com o valor de 1.

- O comando dh não irá aceitar nenhum dos parâmetros de "controle de sequência manua"
descontinuados (--before, --after, etc.). Por favor utilize alvos de sobreposição em vez
destes.

Retroactively applied to earlier compat levels: dh já não aceita nenhum destes desde o
debhelper/12.4.

- O comando dh não irá mais usar ficheiros log para seguir quais comandos foram executados. O
comando dh ainda mantêm o seguimento se já correu a sequência de "compilação" e salta-a se já
o fez.

Os principais efeitos disto são:

- Com isto, é agora mais fácil de depurar as sequências install ou/e binary porque agora
podem ser trivialmente re-executadas (sem ter que fazer um ciclo de "limpar e recompilar"
completo.

- O principal embargo é que dh_* agora apenas mantêm acompanhamento do que aconteceu num
alvo de sobreposição singular. Quanto todas as chamadas a um dado comando dh_cmd
acontecem no mesmo alvo de sobreposição tudo irá funcionar como dantes.

Exemplo de onde pode falhar:

override_dh_foo:
dh_foo -pmy-pkg

override_dh_bar:
dh_bar
dh_foo --remaining

Neste caso, a chamada a dh_foo --remaining irá também incluir my-pkg, desde que dh_foo
-pmy-pkg tenha corrido num alvo de sobreposição separado. Este problema não está imitado
a --remaining, mas também inclui -a, -i, etc.

- O comando dh_installdeb agora faz "escape de shell" às linhas no ficheiro de configuração de
maintscript. Esta foi a intenção original mas não trabalhava correctamente e os pacotes
começaram a confiar no "escapar de shell" incompleto (ex. ao mencionar nomes de ficheiros).

- O comando dh_installinit agora usa por predefinição --restart-after-upgrade. Para pacotes que
precisam do comportamento anterior, por favor use --no-restart-after-upgrade.

- A sequência autoreconf é agora activada por predefinição. Por favor passe --without
autoreconf ao dh se isto não for desejável para um determinado pacote

- A sequência systemd é agora activada por predefinição. Por favor passe --without systemd ao
dh se isto não for desejável para um determinado pacote.

- Retroactively removed dh já não cria o directório de compilação do pacote quando salta a
execução de comandos debhelper. Isto não vai afectar pacotes que apenas compilam com comandos
debhelper, mas pode expor bugs em comandos não incluídos no debhelper.

Esta funcionalidade de compatibilidade tinha um bug desde a sua inserção no
debhelper/9.20130516 que o fazia falhar ao aplicar em compatibilidade 9 e anteriores. Como
não tem havido relatórios de problemas causados por este bug nesses -5 anos, este item foi
removido em vez de corrigido.

v11 Este modo está desencorajado.

A compatibilidade 11 é desencorajada para novos pacotes pois sofre de interação de características
entre dh_installinit e dh_installsystemd o que causa com que os serviços não funcionem correctamente
em alguns casos. Por favor considere usar modo de compatibilidade 10 ou 12 em vez deste. Mais
detalhes sobre este problema estão disponíveis em Debian#887904 e
<https://lists.debian.org/debian-release/2019/04/msg01442.html>.

As alterações a partir de v10 são:

- dh_installinit já não instala ficheiros service ou tmpfile, nem gera scripts do maintainer
para esses ficheiros, Por favor use o novo ajudante dh_installsystemd

- Os ajudantes dh_systemd_enablee dh_systemd_start foram substituídos pelo novo ajudante
dh_installsystemd. Pela mesma razão, a sequência do systemd para dh foi também removida. Se
você precisar de desactivar a ferramenta de ajuda dh_installsystemd, por favor use um alvo de
sobreposição vazio.

Por favor note que a ferramenta dh_installsystemd tem um comportamento ligeiramente diferente
em alguns casos (ex. quando se usa o parâmetro --name).

- dh_installdirs já não cria directórios debian/pacote a menos que tal seja explicitamente
pedido (ou se tiver de criar um sub-directório nele).

A grande maioria dos pacotes não serão afectados por esta alteração.

- O sistema de compilação makefile agora passa INSTALL="install --strip-program=true" para o
make(1). Sistemas de compilação derivativos (ex. configure ou cmake) não são afectados por
esta alteração.

- O sistema de compilação autoconf agora passa --runstatedir=/run para ./configure.

- O sistema de compilação cmake agora passa -DCMAKE_INSTALL_RUNSTATEDIR=/run para cmake(1).

- dh_installman irá agora preferir detectar a linguagem a partir do nome de caminho em vez de a
extensão.

- dh_auto_install irá agora apenas criar o directório de destino que precisa. Anteriormente,
iria criar o directório de compilação de pacote para todos os pacotes. Isto não vai afectar
pacotes que apenas compilam com comandos debhelper, mas pode expor bugs em comandos não
incluídos no debhelper.

- Os ajudantes dh_installdocs, dh_installexamples, dh_installinfo, e dh_installman agora dão
erro se a sua configuração tiver um padrão que não coincida com nada ou faça referência a um
caminho que não exista.

Excepções conhecidas incluem compilar com o perfil nodoc, onde as ferramentas de cima irão
permitir em silêncio correspondências falhadas onde os padrões são usados para especificar
documentação.

- Os ajudantes dh_installdocs, dh_installexamples, dh_installinfo, e dh_installman agora
aceitam o parâmetro --sourcedir com o mesmo significado que dh_install. Mais ainda, eles
agora também retornam (em fall back) a debian/tmp como dh_install.

Nota de migração: Um bug no debhelper 11 até ao 11.1.5 faz com que dh_installinfo ignore
incorrectamente --sourcedir.

- Os sistemas de compilação perl-makemaker e perl-build já não passam -I. ao perl. Os pacotes
que ainda precisam deste comportamento podem emula-lo ao usar a variável de ambiente
PERL5LIB. Ex. ao adicionar export PERL5LIB=. no seu ficheiro debian/rules (ou semelhante).

- A variável de ambiente PERL_USE_UNSAFE_INC já não é definida pelo dh ou nenhuma das
ferramentas dh_auto_*. Ela foi adicionada como um meio de contorno temporário evitar muitos
pacotes a falharem a compilação ao mesmo tempo.

Note que este item irá eventualmente tornar-se obsoleto pois o auto pretende abandonar o
suporte para a variável de ambiente PERL_USE_UNSAFE_INC. Quando o perl abandonar o para ala,
então esta variável será também removida retroactivamente dos níveis de compatibilidade
existentes.

- O ajudante dh_makeshlibs irá agora terminar em erro se objdump retornar uma saída não-zero a
partir da análise de um determinado ficheiro.

- As ferramentas dh_installdocs e dh_installexamples podem agora instalar a maioria da
documentação num caminho diferente para cumprir com a recomendação da política Debian §12.3
(desde versão 3.9.7).

Note que um dado pacote fonte apenas contém um único pacote binário em debian/control ou
nenhum dos pacotes são pacotes -doc, então esta alteração não é relevante para esse pacote
fonte e você pode saltar a próxima alteração.

Por predefinição, estas ferramentas irão agora tentar determinar um "pacote principal para a
documentação" (chamado um doc-main-package daqui em diante) para cada pacote -doc. Se
encontrarem o tal doc-main-package, irão agora instalar a documentação em /usr/share/doc/doc-
main-package no pacote doc fornecido. Isto é, o caminho pode mudar mas a documentação será na
mesma enviada no pacote -doc.

A opção --doc-main-package pode ser usada quando a auto-detecção é insuficiente ou para
reiniciar o caminho para o seu valor anterior se existir razão para divergir da recomendação
da política Debian.

Alguma documentação não será afectada por esta alteração. Estas excepções incluem o ficheiro
copyright, ficheiros changelog, README.Debian, etc. Estes ficheiros serão na mesma instalados
no caminho /usr/share/doc/pacote.

- As ferramentas dh_strip e dh_shlibdeps já não usam mais padrões de nomes de ficheiros para
determinar quais ficheiros processar. Em vez disso, elas abrem o ficheiro e procuram um
cabeçalho ELF para determinar se um dado ficheiro é um objecto partilhado ou um executável
ELF.

Esta alteração fazer com que as ferramentas processem mais ficheiros que anteriormente.

v12 As alterações a partir de v11 são:

- A ferramenta dh_makeshlibs agora gera ficheiros shlibs com dependência de versão por
predefinição. Isto significa que -VUpstream-Version (a.k.a. -V) é agora a predefinição.

Se é pedida uma dependência sem versão no ficheiros shlibs, isto pode ser conseguido ao
passar -VNone em substituição. No entanto, por favor veja dh_makeshlibs(1) para a
problemática das dependências sem versão.

- A opção -s (--same-arch) foi removida. Por favor use -a (--arch) em vez desta.

- Invocar dh_clean -k agora causa um erro em vez de um aviso de descontinuação.

- A opção --no-restart-on-upgrade em dh_installinit foi removida. Por favor use o novo nome
--no-stop-on-upgrade

- Existia um bug nas funções doit (e similares) a partir de Debian::Debhelper::Dh_Lib que fazia
aparece uma linha de comandos numa circunstância particular. Este bug foi agora removido e
irá fazer com que os ajudantes que contavam com esse bug falhem com um erro de "comando não
encontrado".

- O --list-missing e --fail-missing em dh_install foram removidos. Por favor use dh_missing e
as suas opções correspondentes, o qual pode também ver os ficheiros instalados por outros
ajudantes.

- O ajudante dh_installinit já não instala configuração para o sistema de init upstart. Em vez
disso, irá abortar a compilação se encontrar um ficheiro de configuração upstart antigo. O
erro está lá para lembrar ao maintainer do pacote para assegurar a remoção apropriada dos
ficheiros de configuração empacotados em versões anteriores do pacote (caso existam).

- A ferramenta dh_installdeb irá fazer validação básica de alguns comandos
dpkg-maintscript-helper(1) e irá terminar em erro se os comandos parecerem ser inválidos.

- A ferramenta dh_missing irá agora usar por predefinição --list-missing.

- A ferramenta dh_makeshlibs irá agora apenas passar bibliotecas para dpkg-gensymbols(1) se o
binário ELF tiver um SONAME (contendo ".so").

- A ferramenta dh_compress não mais comprime exemplos (isto é, nada instalado em
</usr/share/doc/pacote/examples>.)

- A sequência standard em dh agora inclui dh_dwz e dh_installinitramfs por predefinição. Isto
tornas as sequências dwz e installinitramfs obsoletas e elas agora irão falhar com um erro.
Se desejar saltar estes comandos, por favor insira um alvo de sobreposição vazio para eles em
debian/rules (ex. override_dh_dwz:)

- Os sistemas de compilação meson e autoconf não mais definem explicitamente a variável
--libexecdir e assim apoia-se na predefinição do sistema de compilação - O qual deve ser
/usr/libexec (por FHS 3.0, adoptado em Debian Policy 4.1.5).

Se um determinado pacote original do autor não usar a predefinição correcta, o parâmetro pode
muitas vezes ser passado manualmente via dh_auto_configure(1). Por exemplo via seguinte
exemplo:

override_dh_auto_configure:
dh_auto_configure -- --libexecdir=/usr/libexec

Note o -- antes do parâmetro --libexecdir.

- Retroativamente removido em debhelper/13.5:

A ferramenta dh_installdeb não iria mais instalar o ficheiro conffiles fornecido pelo
responsável pois isso foi considerado desnecessário. No entanto, o remove-on-upgrade do
dpkg/1.20 tornou o ficheiro relevante de novo e dh_installdeb agora instala-o nos níveis de
compatibilidade 12+.

- A ferramenta dh_installsystemd não mais se apoia em dh_installinit para lidar com os serviços
do systemd que têm uma alternativa de sysvinit. ambas ferramentas devem agora ser usadas em
tais casos para assegurar que o serviço é arrancado correctamente sob ambos sysvinit e
systemd.

Se tiver uma sobreposição para dh_installinit (ex. para chamá-lo com --no-start) então irá
provavelmente precisar agora também de um para dh_installsystemd.

Esta alteração faz dh_installinit injectar um misc:Pre-Depends para init-system-helpers (>=
1.54~). Por favor assegure que o pacote lista ${misc:Pre-Depends} no seu campo Pre-Depends
antes de actualizar para a compatibilidade 12.

- Esta ferramenta de terceiros dh_golang (do pacote dh-golang) agora por predefinição honra a
variável DH_GOLANG_EXCLUDES para instalação fonte em pacotes -dev e não apenas durante o
processo de compilação. Por favor defina DH_GOLANG_EXCLUDES_ALL para falso para reverter para
o comportamento anterior. Veja Debian::Debhelper::Buildsystem::golang(3pm) para detalhes e
exemplos

- dh_installsystemduser é agora incluído na sequência standard do dh por predefinição.

- O sistema de compilação python-distutils foi agora removido. Por favor use o sistema de
compilação de terceiros pybuild em substituição.

v13 Este é o modo de operação recomendado.

As alterações a partir de v12 são:

- O sistema de compilação meson+ninja agora usa meson test em vez de ninja test quando corre a
suite de testes. Qualquer sobreposição de dh_auto_test que passe parâmetros extra ao testador
original do autor deve ser revista, pois o meson test não é compatível em linha de comandos
com o ninja test.

- Todas as ferramentas tipo debhelper baseadas na biblioteca debhelper oficial (incluindo dh e
as ferramentas oficiais dh_*) não aceitam mais parâmetros abreviados de comandos. Ao mesmo
tempo, dh agora optimiza as chamadas a ajudantes redundantes dh_* mesmo quando passa opções
longas da linha de comandos.

- As ferramentas debhelper relacionadas com ELF (dh_dwz, dh_strip, dh_makeshlibs, dh_shlibdeps)
são agora apenas executadas para os pacotes dependentes de arquitectura por predefinição
(isto é, estão excluídas de alvos *-indep e são passadas -a por predefinição). Se você
precisar delas para alvos *-indep, você pode adicionar um Build-Depends explícito em dh-
sequence-elf-tools.

- O sistema de compilação de terceiros gradle (do pacote gradle-debian-helper) agora corre a
suite de testes disponibilizada pelo autor automaticamente. Para suprimir tal comportamento,
sobreponha dh_auto_test.

- A ferramenta dh_installman agora aborta se vir definições conflituosas de uma manpage. Isto
tipicamente acontece se o sistema de compilação do autor está a instalar uma versão
comprimida e o pacote lista uma versão descomprimida da manpage em debian/package.manpages.
Muitas vezes a correção mais fácil é remover a manpage de debian/package.manpages (assumindo
que ambas as versões são idênticas).

- Os ajudantes de dh_auto_* agora reiniciam as variáveis de ambiente HOME e variável comum
XDG_*. Por favor veja a descrição das variáveis de ambiente em "ENVIRONMENT" para como lidar
com isto.

Esta funcionalidade mudou entre debhelper 13 e debhelper 13.2.

- O comando dh ir+a agora dar erro se estiver presente um alvo de sobreposição ou hook para um
comando obsoleto em debian/rules (ex.override_dh_systemd_enable:).

- O comando dh_missing irá agora usar por predefinição --fail-missing. Isto pode ser revertido
para um aviso não fatal ao passar explicitamente --list-missing como era na compatibilidade
12.

Se você também não quiser o aviso, por favor omita a chamada ao dh_missing. Se você usar o
sequenciador de comandos dh, então pode fazer isto ao inserir um alvo de sobreposição vazio
no ficheiro debian/rules do pacote relevante. Como exemplo:

# Disable dh_missing
override_dh_missing:

- O sequenciador de comandos dh agora corre dh_installtmpfiles na sequência predefinida. O
dh_installtmpfiles assume o manusear dos ficheiros de configuração tmpfiles.d. A
funcionalidade relacionada em dh_installsystemd está agora desactivada.

Note que dh_installtmpfiles responde a debian/package.tmpfiles onde dh_installsystemd usou um
nome sem o "s" final.

- Muitas ferramentas dh_* agora suportam expansão de variáveis limitada via sintaxe ${foo}. Em
muitos casos, isto pode ser usado para referenciar caminhos que contêm ou espaços ou valores
dpkg-architecture(1). Enquanto isto pode reduzir a necessidade de dh-exec(1) em alguns casos,
não é um substituto de dh-exec(1) em geral. Se você precisar de filtrar, renomear, etc... o
pacote irá continuar a precisar de dh-exec(1).

Por favor veja "Substituições em ficheiros de configuração do debhelper" para sintaxe e
variáveis de substituição disponíveis. Para os escritores da ferramenta dh_*, a expansão de
substituição ocorre como parte das funções filearray e filedoublearray.

- O sequenciador de comandos dh irá agora saltar todos os alvos hook e de sobreposição para
dh_auto_test, dh_dwz e dh_strip quando DEB_BUILD_OPTIONS listar as opções nocheck / nostrip
relevantes.

Qualquer pacote que se apoie nestes alvos para ser sempre corrido deve, em vez disto, mover a
lógica relevante para fora destes alvos. Ex, código de empacotamento não relacionado com
testes a partir de override_dh_auto_test deverá ser movido para execute_after_dh_auto_build
ou execute_before_dh_auto_install.

- O sistema de compilação cmake agora passa -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON ao cmake(1)
para acelerar o processo de instalação automática. Se por alguma razão você precisar do
comportamento anterior, sobreponha a flag:

dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...

v14 Este nível de compatibilidade ainda está aberto em desenvolvimento; use com cuidado.

As alterações a partir de v13 são:

- O sistema de compilação cmake agora passa -DCMAKE_SKIP_RPATH=ON e
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON a cmake(1) para evitar alguns problemas de
reprodutibilidade.

Isto pode causar problemas com o correr binários directamente dos directórios de compilação
pois eles podem não requerer uma LD_LIBRARY_PATH definida manualmente. Se você precisa de
sobrepor esta alteração, nós recomendamos que tente passar a opção -DCMAKE_SKIP_RPATH=OFF
primeiro para ver se isso corrige o problema (deixando CMAKE_BUILD_RPATH_USE_ORIGIN na sua
nova predefinição). Isto deve desfazer a necessidade de LD_LIBRARY_PATH e evitar os problemas
de reprodutibilidade em Linux, onde $ORIGIN é suportado pelos vinculadores de
tempo-de-execução.

- The tool dh_installsysusers is now included in the default sequence. It will cause units to
be automatically started on installation, restarted on upgrade and stopped on removal for
every systemd user instance running on the system.

- Usar o comando dh_gconf em alvos de sobreposição e hook agora causa um erro. O comando
dh_gconf foi um não-operativo durante anos e foi removido no debhelper 13.4.

- O sequenciador dh irá avisar se o addon single-binary for activado implicitamente para avisar
os maintainers da pendente alteração na compatibilidade 15 em dh_auto_install.

Maintainers são incentivados a ou activar explicitamente o addon single-binary para preservar
o comportamento existente (ex. ao adicionar <dh-sequence-single-binary> a Build-Depends), ou
passar explicitamente --destdir a dh_auto_install se usado e depois passar --without single-
binary a dh (a última para silenciar o aviso).

A razão para esta alteração é evitar "surpresas" ao adicionar um segundo pacote binário mais
tarde. Anteriormente, o debhelper iria em silêncio alterar o comportamento muitas vezes
resultado em pacotes binários vazios a serem enviados para o arquivo por engano. Com o novo
comportamento, o addon single-binary irá detectar a discrepância e avisar o maintainer do que
está prestes a acontecer.

v15 Este nível de compatibilidade ainda está aberto em desenvolvimento; use com cuidado.

As alterações a partir de v14 são:

- A ferramenta dh_auto_install já não usa por predefinição --destdir=debian/package para
pacotes fonte que apenas produzem um único binário. Se este comportamento é desejado, o
pacote deve activar explicitamente o addon do dh single-binary (ex. ao adicionar dh-sequence-
single-binary a Build-Depends) ou passar --destdir a dh_auto_install.

NOTAS

Suporte a pacotes de múltiplos binários
Se o seu pacote fonte gerar mais do que um pacote binário, os programas do debhelper, por predefinição,
irão actuar em todos os pacotes binários quando correm. No caso do seu pacote fonte gerar um pacote
dependente de arquitectura, e outro pacote independente da arquitectura, este não é o comportamento
correcto, porque você precisa de gerar os pacotes dependentes de arquitectura no alvo debian/rules
binary-arch, e os pacotes independentes de arquitectura no alvo debian/rules binary-indep.

Para facilitar isto, e também para lhe dar mais controle sobre em quais pacotes os programas debhelper
actuam, todos os programas debhelper aceitam os parâmetros -a, -i, -p, e -s. Estes parâmetros são
cumulativos. Se nenhum for usado, os programas debhelper por predefinição actuam em todos os pacotes
listados no ficheiro de controle, com as excepções em baixo.

Primeiro, qualquer pacote cujo campo Architecture em debian/control não corresponda à arquitectura
DEB_HOST_ARCH será excluído ("Debian Policy, secção 5.6.8").

Também, alguns pacotes adicionais podem ser excluídos com base no conteúdo da variável de ambiente
DEB_BUILD_PROFILES e nos campos Build-Profiles nas estrofes de pacotes binários em debian/control, de
acordo com a política proposta em <https://wiki.debian.org/BuildProfileSpec>.

Interacção entre selecções de pacotes e Build-Profiles

Build-Profiles afectam quais pacotes são incluídos nos mecanismos de selecção de pacotes do debhelper.
Geralmente, as selecções de pacotes são descritas a partir do pressuposto que todos os pacotes estão
activados. Esta secção descreve como as selecções reagem quando um pacote é desactivado devido a Build-
Profiles activos (ou a falta de Build-Profiles activos).

-a/--arch, -i/--indep OU nenhuma opção de selecção (uma chamada "dh_X" crua)
O pacote desactivado por Build-Profiles é excluído em silêncio da selecção.

Note que vai receber um aviso se todos os pacotes relacionados com estas selecções estiverem
desactivados. Nesse caso, geralmente não faz nenhum sentido sequer fazer a compilação.

-N package / --no-package package
A opção é aceite e efectivamente não faz nada.

-p package / --package package
A opção é aceite, mas o debhelper não irá actuar no pacote.

Note que não importa se um pacote está activado ou desactivado por predefinição.

Geração automática de scripts de instalação Debian
Alguns comandos do debhelper irão gerar automaticamente partes de scripts de maintainer Debian. Se
desejar que estas coisas geradas automaticamente sejam incluídas nos sues scripts de maintainer Debian
existentes, então você precisa adicionar #DEBHELPER# aos seus scripts, no local onde o código deverá ser
adicionado. #DEBHELPER# será substituído por qualquer código auto-gerado quando você correr o
dh_installdeb.

Se não existir nenhum script e o debhelper precisar de adicionar algo a ele, então o debhelper irá criar
o script completo.

Todos os comandos debhelper que geram código automaticamente deste modo permitem que o seja desactivado
pelo parâmetro -n (ver em cima).

Note que o código inserido será código shell, portanto você não pode usá-lo directamente num script de
Perl. Se desejar embebê-lo num script Perl, aqui está um modo de o fazer (note que Eu certifico-me que
$1, $2, etc são definidos com o comando "set"):

my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
#DEBHELPER#
EOF
if (system($temp)) {
my $exit_code = ($? >> 8) & 0xff;
my $signal = $? & 0x7f;
if ($exit_code) {
die("The debhelper script failed with error code: ${exit_code}");
} else {
die("The debhelper script was killed by signal: ${signal}");
}
}

Geração automática de dependências variadas.
Alguns programas debhelper podem fazer com que o pacote gerado precise de depender de alguns outros
pacotes. Por exemplo, se você usar o dh_installdebconf(1), o seu pacote irá geralmente depender do
debconf. Ou se você usar dh_installxfonts(1), o seu pacote irá geralmente depender de uma versão
particular do xutils. Acompanhar estas dependências variadas pode ser aborrecido pois elas dependem de
como o debhelper faz as coisas, então o debhelper oferece um modo de automatizar isto.

Todos os comandos deste tipo, além de documentar quais dependências podem ser necessárias nos seus
manuais, irão gerar automaticamente um substvar chamado ${misc:Depends}. Se você colocar esse token no
seu ficheiro debian/control, será expandido às dependências que o debhelper descobre que você precisa.

Isto é inteiramente independente do standard ${shlibs:Depends} gerado pelo dh_makeshlibs(1), e do
${perl:Depends} gerado pelo dh_perl(1). Você pode escolher usar qualquer um destes, se as escolhas do
debhelper não corresponderem à realidade.

Directórios de compilação de pacotes
Por predefinição, todos os programas do debhelper assumem que o directório temporário usado para montar a
árvore de ficheiros num pacote é debian/pacote.

Por vezes, você pode querer usar outro directório temporário. Isto é suportado pela bandeira -P, por
exemplo, "dh_installdocs -Pdebian/tmp", irá usar debian/tmp como directório temporário. Note que se você
usar -P, os programas debhelper só podem actuar num pacote de cada vez. Por isso se tem um pacote que
compila muitos pacotes binários, irá também precisar de usar a bandeira -p para especificar em qual
pacote binário o programa debhelper irá actuar.

udebs
Debhelper inclui suporte para udebs. Para criar um udeb com o debhelper, adicione "Package-Type: udeb" à
estrofe do pacote em debian/control. O Debhelper irá tentar criar udebs em conformidade com a política do
instalador debian, ao finalizar os ficheiros de pacotes gerados com .udeb, não instalando nenhuma
documentação num udeb, saltando os scripts preinst, postrm, prerm, e config, etc.

AMBIENTE

Esta secção descreve algumas das variáveis de ambiente que influenciam o comportamento do debhelper ou de
quem o debhelper interage.

É importante notar que estas que estas têm de ser mesmo variáveis de ambiente de modo a afectarem o
comportamento do debhelper (e não simplesmente variáveis do Makefile). Para as especificar correctamente
em debian/rules, assegure-se de lhes fazer "export". Por exemplo, "export DH_VERBOSE"

DH_VERBOSE
Defina para 1 para activar o modo detalhado. O debhelper irá mostrar os resultados de cada comando
que corre. Também activa relatórios de compilação detalhados para alguns sistemas de compilação como
o autoconf.

DH_QUIET
Definir para 1 para activar o modo silencioso. O Debhelper não irá escrever os comandos a chamar o
sistema de compilação do autor nem o dh irá escrever quais sub-comandos são chamados e dependendo do
sistema de compilação do autor, poderá também tornar isso mais silencioso. Isto facilita a
identificação de mensagens importantes mas torna os resultados inúteis como relatório do buildd. É
ignorado se DH_VERBOSE for também definido.

DH_COMPAT
Especifica temporariamente em que nível de compatibilidade o debhelper deve correr, sobrepondo
qualquer valor especificado via Build-Depend em debhelper-compat ou via ficheiro debian/compat.

DH_NO_ACT
Defina para 1 para activar o modo no-act.

DH_OPTIONS
Todas as ferramentas debhelper irão processar os argumentos de linha de comandos listados nesta
variável antes de qualquer opção de comando (como se eles fossem anexados aos argumentos de linha de
comandos). Infelizmente, algumas ferramentas disponibilizadas por terceiros podem não suportar esta
variável e irão ignorar estes argumentos de linha de comandos.

Quando se usa dh(1), podem-se passar opções que irão ser passadas a cada comando do debhelper, o que
é geralmente melhor do que usar DH_OPTIONS.

DH_ALWAYS_EXCLUDE
Se definido, isto adiciona o valor que está definido na variável às opções -X de todos os comandos
que suportam a opção -X. Ainda mais, o dh_builddeb irá fazer rm -rf a tudo o que corresponda a esse
valor na sua árvore de compilação do pacote.

Isto pode ser útil se você está a fazer uma compilação a partir de uma árvore fonte CVS, que no caso
definindo DH_ALWAYS_EXCLUDE=CVS irá prevenir que quaisquer directórios CVS se esgueirem para o pacote
que está a compilar. Ou, se um pacote tem um tarball de fonte que (não inteligentemente) inclui
directórios CVS, você pode querer exportar DH_ALWAYS_EXCLUDE=CVS em debian/rules, para o fazer ter
efeito onde o seu é compilado.

Várias coisas a excluir podem ser separadas com "dois pontos", como em DH_ALWAYS_EXCLUDE=CVS:.svn

DH_EXTRA_ADDONS
Se definido, isto adiciona os addons especificados do dh para serem corridos nos lugares apropriados
na sequência de comandos. Isto é equivalente a especificar o addon a correr coma bandeira --with no
ficheiro debian/rules file. Qualquer chamada --without que especifique um addon nesta variável de
ambiente não será executada.

Isto destina-se a ser usado por downstreams ou configurações locais especificas que requeiram a
execução dum addon do debhelper durante múltiplas compilações sem terem que aplica patch a um grande
número de ficheiros de regras. Se de todo possível, isto deve ser evitado em favor de uma bandeira
--with no ficheiro rules.

DH_COLORS, DPKG_COLORS
Estas variáveis podem ser usadas para controlar se os comandos do debhelper devem usar cores nos
resultados textuais. Podem ser definidas para "always", "auto" (a predefinição), ou "never".

Note que DPKG_COLOR também afecta um número de ferramentas relacionadas ao dpkg e o debhelper usa-o
na suposição que você quer a mesma definição de cor para o dpkg e debhelper. Na hipótese de você
querer definição de cor diferente para o debhelper, pode usar DH_COLORS em vez disso ou em adição a
DPKG_COLORS.

NO_COLOR
Se não for fornecido um pedido específico para cor (ex. DH_COLORS e DPKG_COLORS estão ambos
não-definidos), a presença desta variável de ambiente faz com que a definição de cor predefinida seja
"never".

A variável é definida de acordo com <https://no-color.org/>. Neste projecto, as variáveis de
ambiente (tais como DH_COLORS) são consideradas um requisito explícito para cor.

CFLAGS, CPPFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS, FCFLAGS, LDFLAGS
Por predefinição (em qualquer nível de compatibilidade não-abandonado). o debhelper irá
automaticamente definir estas flags ao usar dpkg-buildflags(1), quando não estiverem definidas. Se
você precisar de modificar as flags predefinidas, por favor use as funcionalidades de
dpkg-buildflags(1) para o fazer (ex. DEB_BUILD_MAINT_OPTIONS=hardening=all ou
DEB_CPPFLAGS_MAINT_APPEND=-DCUSTOM_MACRO=true) em vez de definir a variável concreta directamente.

HOME, XDG_*
Em compatibilidade 13 e posterior, estas variáveis de ambiente são reiniciadas antes de invocar o
sistema de compilação do autor via ajudantes do dh_auto_*. As variáveis HOME (todos os ajudantes
dh_auto_*) e XDG_RUNTIME_DIR (apenas dh_auto_test) irão ser definidas para um directório gravável.
Todas as restantes variáveis e XDG_RUNTIME_DIR (excepto para durante dh_auto_test) irão ser limpas.

O directório HOME será criado como um directório vazio mas ele será reutilizado entre chamadas a
dh_auto_*. Qualquer conteúdo irá persistir até ser explicitamente apagado ou dh_clean.

DEB_BUILD_OPTIONS
Por favor veja "Bandeiras suportadas em DEB_BUILD_OPTIONS" para esta variável de ambiente.

Por favor note que esta variável não deve ser alterada por maintainers de pacote dentro de
debian/rules para mudar o comportamento do debhelper. Em vez disso, onde o maintainer do pacote
precisar destas funcionalidades, eles devem procurar desactivar a funcionalidade relevante
directamente (ex. ao sobrepor as ferramentas concretas).

DEB_MAINT_BUILD_OPTIONS
Esta é uma variável de ambiente especifica do dpkg (veja por ex. dpkg-buildflags(1)). A suite de
ferramentas do debhelper ignora-a em silêncio.

Está documentada aqui porque tem um nome semelhante a DEB_BUILD_OPTIONS, o que faz com que algumas
pessoas assumam em erro que o debhelper também vai reagir a esta variável.

Bandeiras suportadas em DEB_BUILD_OPTIONS
A suite de ferramentas debhelper reage às seguintes bandeiras em DEB_BUILD_OPTIONS.

dherroron=obsolete-compat-levels
Este é um valor específico do debhelper.

Quando dherroron está presente e definida para obsolete-compat-levels, então as ferramentas debhelper
irão promover para erros os avisos de descontinuidade de níveis de compatibilidade antigos e prestes
a serem removidos.

Isto é útil para verificação automática de confiança de código em níveis de compatibilidade
descontinuados que estão agendados para remoção.

Esta opção destina-se a objectivos de teste; não compilações produtivas.

nostrip
Este valor irá mudar o conteúdo dos debs a serem compilados. Os pacotes .deb compilados quando isto
está definido são por isto não reproduzíveis bit-a-bit com uma compilação regular nas generalidade
dos casos.

Este valor irá fazer com que as ferramentas oficiais debhelper saltem acções e ajudantes que ou
removem, desanexam ou duplicam símbolos em binários ELF.

Este valor afecta dh_dwz(1) e dh_strip(1).

nocheck
Este valor irá fazer com que os sistemas de compilação oficiais debhelper saltem execuções de suites
de testes do autor original.

Os maintainers de pacotes que procurem evitar correr os testes do autor não devem confiar nisto. Em
vez disto, eles podem adicionar um alvo de sobreposição vazio para saltar o dh_auto_test.

Este valor afecta dh_auto_test(1).

nodoc
Este valor irá mudar o conteúdo dos debs a serem compilados. Os pacotes .deb compilados quando isto
está definido são por isto não reproduzíveis bit-a-bit com uma compilação regular nas generalidade
dos casos.

Este valor irá fazer com que várias ferramentas debhelper saltem a instalação de documentação tal
como os manuais ou documentação fornecida pelo autor original. Adicionalmente, as ferramentas irão
também ignorar se a documentação declarada está "em falta" assumindo que a documentação não foi
compilada.

Este valor afecta ferramentas do tipo dh_installdocs(1), que sabem que estão a trabalhar com
documentação.

noautodbgsym, noddebs
O nome oficial é autodbgsym. A variante noddebs é aceite por razões históricas.

Este valor faz com que o debhelper salte a geração de pacotes de símbolos de depuração gerados
automaticamente.

Este valor afecta dh_strip(1).

parallel=N
Este valor habilita o debhelper a usar até N linhas de processos (sujeitos a parâmetros como
--no-parallel e --max-parallel=M). Nem todas as ferramentas debhelper trabalham com tarefas
paralelas e podem ignorar o pedido em silêncio.

Este valor afecta muitas ferramentas debhelper. Mais notoriamente dh_auto_*, a qual irá tentar correr
o sistema de compilação subjacente do autor com esse número de linhas de execução.

terse
Este valor irá fazer com que os sistemas de compilação oficiais debhelper configurem as compilações
do autor para serem concisas (isto é, reduzir os detalhes dos seus resultados). Isto está sujeito a
que os sistemas de compilação do autor e do debhelper suportem tais funcionalidades.

Este valor afecta a maioria das ferramentas dh_auto_*.

Bandeiras desconhecidas são ignoradas em silêncio.

Note que ferramentas de terceiros estilo-debhelper ou sistemas de compilação fornecidos por terceiros
podem não reagir às bandeiras em cima. Isto tende a depender dos detalhes de implementação da ferramenta.

VEJA TAMBÉM

       /usr/share/doc/debhelper/examples/
           Um conjunto de ficheiros debian/rules exemplo que usam debhelper.

       <http://joeyh.name/code/debhelper/>
           Sítio web do debhelper.

AUTOR

       Joey Hess <joeyh@debian.org>

TRADUÇÃO

       Américo Monteiro

       Se  encontrar  algum  erro  na  tradução  deste  documento,  por  favor  comunique  para Américo Monteiro
       a_monteiro@gmx.com ou Equipa Debian de Tradução Portuguesa traduz@debianpt.org.

13.6ubuntu1                                        2022-02-07                                       debhelper(7)