debhelper(7) | Debhelper | debhelper(7) |
debhelper - a suite de ferramentas debhelper
dh_* [-v] [-a] [-i] [--no-act] [-ppackage] [-Npackage] [-Ptmpdir]
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.
Aqui está a lista dos comandos debhelper que você pode usar. Veja os seus manuais para documentação adicional.
Alguns comandos debhelper estão descontinuados e não devem ser usados.
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.
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.
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:
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:
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.
# 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.
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.
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).
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:
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.
As seguintes opções de linha de comandos são suportadas por todos os programas do debhelper.
Esta opção foi removida no nível de compatibilidade 12.
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.
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_*.
Passa none como buildsystem para desactivar a auto-selecção.
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).
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.
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).
De notar que, definir o máximo para 1 é efectivamente o mesmo que usar --no-parallel.
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.
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.
Estes são os níveis de compatibilidade disponíveis:
Se você está a actualizar a partir de um nível de compatibilidade anterior, por favor reveja debhelper-obsolete-compat(7).
Este modo está descontinuado.
Este modo está descontinuado.
Este modo está descontinuado.
Este modo está descontinuado.
(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)
Este modo está descontinuado.
Retroactively applied to earlier compat levels: dh já não aceita nenhum destes desde o debhelper/12.4.
Os principais efeitos disto são:
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.
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.
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:
Por favor note que a ferramenta dh_installsystemd tem um comportamento ligeiramente diferente em alguns casos (ex. quando se usa o parâmetro --name).
A grande maioria dos pacotes não serão afectados por esta alteração.
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.
Nota de migração: Um bug no debhelper 11 até ao 11.1.5 faz com que dh_installinfo ignore incorrectamente --sourcedir.
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.
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.
Esta alteração fazer com que as ferramentas processem mais ficheiros que anteriormente.
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.
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.
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.
As alterações a partir de v12 são:
Esta funcionalidade mudou entre debhelper 13 e debhelper 13.2.
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:
Note que dh_installtmpfiles responde a debian/package.tmpfiles onde dh_installsystemd usou um nome sem o "s" final.
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.
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.
dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...
As alterações a partir de v13 são:
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.
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).
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.
Note que não importa se um pacote está activado ou desactivado por predefinição.
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}"); } }
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.
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.
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.
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"
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.
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
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.
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.
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.
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.
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).
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.
A suite de ferramentas debhelper reage às seguintes bandeiras em DEB_BUILD_OPTIONS.
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.
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).
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).
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.
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).
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.
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.
Joey Hess <joeyh@debian.org>
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.
2021-03-06 | 13.3.4 |