.\" -*- mode: troff; coding: utf-8 -*-
.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
.ie n \{\
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "DH 1"
.TH DH 1 2024-03-27 13.15.3 Debhelper
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH NOME
.IX Header "NOME"
dh \- sequenciador de comandos do debhelper
.SH RESUMO
.IX Header "RESUMO"
\&\fBdh\fR \fIsequence\fR [\fB\-\-with\fR \fIaddon\fR[\fB,\fR\fIaddon\fR ...]] [\fB\-\-list\fR] [\fIdebhelper\ opções\fR]
.SH DESCRIÇÃO
.IX Header "DESCRIÇÃO"
\&\fBdh\fR corre uma sequência de comandos do debhelper. As \fIsequência\fRs suportadas correspondem aos alvos de um ficheiro \fIdebian/rules\fR: \fBbuild-arch\fR, \fBbuild-indep\fR, \fBbuild\fR, \fBclean\fR, \fBinstall-indep\fR, \fBinstall-arch\fR, \fBinstall\fR, \fBbinary-arch\fR, \fBbinary-indep\fR, e \fBbinary\fR.
.SH "ALVOS DE SOBREPOSIÇÃO E HOOK"
.IX Header "ALVOS DE SOBREPOSIÇÃO E HOOK"
Um ficheiro \fIdebian/rules\fR que use \fBdh\fR pode sobrepor o comando que é executado em qualquer passo numa sequência, ao se definir um alvo de sobreposição. É também possível injectar um comando antes ou depois de qualquer passo sem afectar o próprio passo.
.SS "Injectando comandos antes e depois de um passo"
.IX Subsection "Injectando comandos antes e depois de um passo"
\&\fINota\fR: Esta funcionalidade requer debhelper 12.8 ou posterior e o pacote tem de usar modo de compatibilidade 10 ou posterior.
.PP
Para injectar comandos antes de \fIdh_command\fR, adicione um alvo chamado \fBexecute_before_\fR\fIdh_command\fR aos ficheiros rules. De modo semelhante, se precisar de injectar comandos após \fIdh_command\fR, adicione o alvo \fBexecute_after_\fR\fIdh_command\fR. Ambos alvos podem ser usados para o mesmo \fIdh_command\fR e também mesmo que o comando seja sobreposto (como descrito em "Sobrepor um comando" em baixo).
.PP
Quando estes alvos estão definidos, \fBdh\fR irá chamar os alvos respetivamente antes ou depois de quando iria invocar \fIdh_command\fR (ou os seus alvos de sobreposição).
.SS "Sobrepor um comando"
.IX Subsection "Sobrepor um comando"
Para sobrepor o \fIdh_command\fR, adicione um alvo chamado \fBoverride_\fR\fIdh_command\fR ao ficheiro de regras. Em vez de correr normalmente \fIdh_command\fR, o \fBdh\fR irá chamar esse alvo. O alvo de sobreposição pode depois correr o comando com opções adicionais, ou em vez disso correr comandos completamente diferentes. Veja exemplos em baixo.
.SS "Alvos de sobreposição e hook dependentes/independentes da arquitectura"
.IX Subsection "Alvos de sobreposição e hook dependentes/independentes da arquitectura"
Os alvos de sobreposição e hook também podem ser definidos para correr apenas quando se compila pacotes dependentes ou independentes da arquitectura. Use alvos com nomes como \fBoverride_\fR\fIdh_command\fR\fB\-arch\fR e \fBexecute_after_\fR\fIdh_command\fR\fB\-indep\fR.
.PP
Esta funcionalidade está disponível desde debhelper 8.9.7 (para alvos de sobreposição) e 12.8 (para alvos hook).
.SS "Alvos completamente vazios"
.IX Subsection "Alvos completamente vazios"
Como uma optimização especial, \fBdh\fR irá saltar um alvo se este estiver completamente vazio e não depender de nenhum outro alvo. Isto é muito útil para alvos de sobreposição, onde o comando irá simplesmente ser saltado sem a sobrecarga de invocar um alvo fantoche.
.PP
Note que o alvo tem de estar completamente vazio para isto funcionar:
.PP
.Vb 3
\&     # Skip dh_bar \- the good and optimized way
\&     # Some rationale for skipping dh_bar goes here
\&     override_dh_bar:
\&
\&
\&
\&     # Skip dh_foo \- the slow way
\&     override_dh_foo:
\&        # Some rationale for skipping dh_foo goes here
\&        # (these comments causes a dummy target to be run)
.Ve
.SS "Verificando se os alvos são apanhados pelo dh"
.IX Subsection "Verificando se os alvos são apanhados pelo dh"
A partir do debhelper 13.10, você pode usar \fBdh_assistant\fR\|(1) para ver quais alvos de sobreposição e hook irão ser vistos pelo \fBdh\fR.  Aqui está um exemplo de execução do \fBdh_assistant\fR\|(1) juntamente com os seus resultados:
.PP
.Vb 10
\&    $ dh_assistant detect\-hook\-targets
\&    {
\&       "commands\-not\-in\-path": [
\&          "dh_foo"
\&       ],
\&       "hook\-targets": [
\&          {
\&             "command": "dh_strip_nondeterminism",
\&             "is\-empty": true,
\&             "package\-section\-param": null,
\&             "target\-name": "override_dh_strip_nondeterminism"
\&          },
\&          {
\&             "command": "dh_foo",
\&             "is\-empty": false,
\&             "package\-section\-param": "\-a",
\&             "target\-name": "override_dh_foo\-arch"
\&          }
\&       ]
\&    }
.Ve
.PP
O \fBcommands-not-in-path\fR é útil para detetar enganos nos nomes de alvo hook. Um valor não\-vazio implica que um ou mais alvos hook estão relacionados com um comando que ou não está instalado ou não existe de todo um comando com esse nome. Geralmente é de valor verificar bem estes casos.
.PP
Adicionalmente, o atributo \fBis-empty\fR para cada alvo hook pode ser usado para se ver se um alvo hook despoleta a optimização "Completely empty targets".
.PP
Se você está interessado noutros atributos, por favor leia o \fBdh_assistant\fR\|(1) para detalhes.
.PP
\fIVerificando se os alvos são apanhados pelo dh (quando o debhelper é mais antigo que 13.10)\fR
.IX Subsection "Verificando se os alvos são apanhados pelo dh (quando o debhelper é mais antigo que 13.10)"
.PP
Em versões antigas do debhelper, você tem de usar \fBdh\fR com \fB\-\-no\-act\fR. Você pode usar o seguinte comando como um exemplo:
.PP
.Vb 6
\&    $ dh binary \-\-no\-act | grep dh_install | head \-n5
\&         dh_installdirs
\&         dh_install
\&         debian/rules execute_after_dh_install
\&         dh_installdocs
\&         dh_installchangelogs
.Ve
.PP
O \fBdebian/rules execute_after_dh_install\fR no resultado, que assinala que \fBdh\fR registou um alvo \fBexecute_after_dh_install\fR e o iria correr directamente após \fBdh_install\fR\|(1).
.PP
Note que "Alvos completamente vazios" irão ser omitidos na listagem em cima. Isto torna um pouco mais difícil detectar se você está a olhar para a omissão de um nome de comando. Mas caso contrário, o princípio continua o mesmo.
.SS "Ressalvas com alvos hook e condicionais makefile"
.IX Subsection "Ressalvas com alvos hook e condicionais makefile"
Se você escolher envolver um alvo hook em condicionais makefile, por favor tenha em mente que \fBdh\fR computa todos os alvos hook em adiantado e guarda em cache o resultado para essa execução. Mais ainda, as condicionais serão invocadas novamente quando \fBdh\fR chamar o alvo hook mais tarde e irá assumir que a resposta não mudou.
.PP
A análise e cache ocorre \fImuitas vezes\fR entes de \fBdh\fR saber se vai compilar pacotes arch:any (\-a) ou/e arch:all (\-i), o que pode produzir resultados confusos \- especialmente quando \fBdh_listpackages\fR\|(1) é parte da condicional.
.PP
A maioria dos problemas podem ser evitados ao tornar o alvo hook incondicional e depois ter o "corpo" a ser parcial ou completamente condicional. Com exemplo:
.PP
.Vb 10
\&      # SIMPLE: It is well\-defined what happens.  The hook target
\&      # is always considered.  The "maybe run this" bit is
\&      # conditional but dh_foo is definitely skipped.
\&      #
\&      # Note: The conditional is evaluated "twice" where its
\&      # influences what happens.  Once when dh check which hook
\&      # targets exist and once when the override_dh_foo hook target
\&      # is run.  If *either* times return false, "maybe run this"
\&      # is skipped.
\&      override_dh_foo:
\&      ifneq (...)
\&          maybe run this
\&      endif
\&
\&      # SIMPLE: This is also well\-defined.  The hook target is always
\&      # run and dh_bar is skipped.  The "maybe run this" bit is
\&      # conditional as one might expect.
\&      #
\&      # Note: The conditional is still evaluated multiple times (in
\&      # different process each time).  However, only the evaluation
\&      # that happens when the hook target is run influences what
\&      # happens.
\&      override_dh_bar:
\&          : # Dummy command to force the target to always be run
\&      ifneq (...)
\&          maybe run this
\&      endif
\&
\&
\&
\&      # COMPLICATED: This case can be non\-trivial and have sharp edges.
\&      # Use at your own peril if dh_listpackages in the conditional.
\&      #
\&      # Here, either dh_baz is run normally OR "maybe run this" is run
\&      # instead.
\&      #
\&      # And it gets even more complicated to reason about if dh needs to
\&      # recurse into debian/rules because you have an "explicit"
\&      # standard target (e.g. a "build\-arch:" target separate from "%:").
\&      ifneq (...)
\&      override_dh_baz:
\&          maybe run this
\&      endif
.Ve
.PP
Estas receitas são também relevantes para alvos de dependência condicional, os quais são muitas vezes vistos numa variante do seguinte exemplo:
.PP
.Vb 5
\&      COND_TASKS =
\&      ifneq (...)
\&      COND_TASKS += maybe\-run\-this
\&      endif
\&      ...
\&
\&      maybe\-run\-this:
\&          ...
\&
\&      # SIMPLE: It is well\-defined what happens.  Either the
\&      # $(COND_TASKS) are skipped or run.
\&      #
\&      # Note: The conditional is evaluated "twice" where its
\&      # influences what happens.  Once when dh check which hook
\&      # targets exist and once when the override_dh_foo hook target
\&      # is run.  If *either* times return false, $(COND_TASKS)
\&      # is skipped.
\&      override_dh_foo: $(COND_TASKS)
\&
\&
\&
\&      # SIMPLE: This is also well\-defined.  The hook target is always
\&      # run and dh_bar is skipped.  The $(COND_TASKS) bit is
\&      # conditional as one might expect.
\&      #
\&      # Note: The conditional is still evaluated multiple times (in
\&      # different process each time).  However, only the evaluation
\&      # that happens when the hook target is run influences what
\&      # happens.
\&      override_dh_bar: $(COND_TASKS)
\&          : # Dummy command to force the target to always be run
\&
\&      # COMPLICATED: This case can be non\-trivial and have sharp edges.
\&      # Use at your own peril if dh_listpackages in the conditional.
\&      #
\&      ifneq (...)
\&      override_dh_baz: $(COND_TASKS)
\&      endif
.Ve
.PP
Em caso de dúvida, escolha o caso \fBSIMPLE\fR relevante nos exemplos em cima que corresponda à sua necessidade.
.SH OPÇÕES
.IX Header "OPÇÕES"
.IP "\fB\-\-with\fR \fIaddon\fR[\fB,\fR\fIaddon\fR ...]" 4
.IX Item "--with addon[,addon ...]"
Adiciona os comandos debhelper especificados pelo addon indicado aos lugares apropriados na sequência de comandos que é executada. Esta opção pode ser repetida mais do que uma vez, ou pode-se listar múltiplos addons separados por vírgulas. Isto é usado quando existe um pacote de terceiros que disponibiliza comandos do debhelper. Veja o ficheiro \fIPROGRAMMING\fR para documentação acerca da sequência de interface de addons.
.Sp
Uma relação \fBBuild-Depends\fR no pacote \fBdh\-sequence\-\fR\fIaddon\fR implica um \fIaddon\fR \fB\-\-with\fR. Isto evita a necessidade de um \fB\-\-with\fR explícito em \fIdebian/rules\fR que apenas duplica o que já está declarado via dependências de compilação em \fIdebian/control\fR. A relação pode (desde 12.5) ser feita opcionalmente via por exemplo, build-profiles.  Isto permite-lhe facilmente desativar um addon que é apenas útil com certos perfis (ex. para facilitar bootstrapping).
.Sp
Desde o debhelper 12.5, que addons podem ser também activados em modo \fBindep\fR\-only (via \fBBuild-Depends-Indep\fR) ou modo \fBarch\fR\-only (via \fBBuild-Depends-Arch\fR). Tais addons estão apenas activos na sequência particular (ex. \fBbinary-indep\fR) o qual simplifica a gestão de dependências para compilações cruzadas (cross-builds).
.Sp
Por favor note que os addons activados via \fBBuild-Depends-Indep\fR ou \fBBuild-Depends-Arch\fR estão sujeitos a limitações adicionais para assegurar que o resultado é determinista mesmo quando o addon está indisponível (ex. durante limpeza). Isto sugere que alguns addons são incompatíveis com essas restrições e só podem ser usadas via \fBBuild-Depends\fR (ou manualmente via \fIdebian/rules\fR). Actualmente, tais addons podem apenas adicionar comandos a sequências.
.IP "\fB\-\-without\fR \fIaddon\fR" 4
.IX Item "--without addon"
O inverso de \fB\-\-with\fR, desactiva a utilização do addon indicado. Esta opção pode ser repetida mais do que uma vez, ou pode desactivar vários addons se os listar separados por vírgulas.
.IP "\fB\-\-list\fR, \fB\-l\fR" 4
.IX Item "--list, -l"
Lista todos os addons disponíveis.
.Sp
Quando chamado apenas com esta opção, o \fBdh\fR pode ser chamado a partir de qualquer directório (isto é, não precisa de acesso a ficheiros de um pacote fonte).
.IP \fB\-\-no\-act\fR 4
.IX Item "--no-act"
Escreve comandos que iriam correr para uma determinada sequência, mas não os corre.
.Sp
Note que o dh normalmente evita correr comandos que sabe que não fazem nada. Com \-\-no\-act, é escrito em sequência a lista completa dos comandos.
.PP
Outras opções passadas a \fBdh\fR são passadas a cada comando que ele corre. Isto pode ser usado para definir uma opção como \fB\-v\fR ou \fB\-X\fR ou \fB\-N\fR, assim como para opções mais especializadas.
.SH EXEMPLOS
.IX Header "EXEMPLOS"
Para ver quais comandos estão incluídos numa sequência, sem realmente fazer nada:
.PP
.Vb 1
\&        dh binary\-arch \-\-no\-act
.Ve
.PP
Este é um ficheiro de regras muito simples, para pacotes onde as sequências de comandos predefinidas funcionam sem opções adicionais.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@
.Ve
.PP
Muitas vezes você vai querer passar uma opção a um comando debhelper específico. A maneira mais fácil de o fazer é adicionar um alvo de sobreposição a esse comando.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@
\&
\&        override_dh_strip:
\&                dh_strip \-Xfoo
\&
\&        override_dh_auto_configure:
\&                dh_auto_configure \-\- \-\-with\-foo \-\-disable\-bar
.Ve
.PP
Por vezes os automatismos \fBdh_auto_configure\fR\|(1) e \fBdh_auto_build\fR\|(1) não conseguem adivinhar  que fazer com um pacote estranho. Aqui está como evitar correr outros comandos quaisquer e em vez disso correr os seus próprios comandos.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@
\&
\&        override_dh_auto_configure:
\&                ./mondoconfig
\&
\&        override_dh_auto_build:
\&                make universe\-explode\-in\-delight
.Ve
.PP
Outro caso comum é esperar fazer algo manualmente antes ou depois de um comando debhelper particular ser executado.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@
\&
\&        # Example assumes debhelper/12.8 and compat 10+
\&        execute_after_dh_fixperms:
\&                chmod 4755 debian/foo/usr/bin/foo
.Ve
.PP
Se você está num debhelper ou nível de compatibilidade antigo, o exemplo de cima terá que ser escrito assim:
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@
\&
\&        # Older debhelper versions or using compat 9 or lower.
\&        override_dh_fixperms:
\&                dh_fixperms
\&                chmod 4755 debian/foo/usr/bin/foo
.Ve
.PP
Por predefinição, as ferramentas Python não são acionadas, devido às alterações contínuas nessa área. Aqui está como usar o \fBdh_python2\fR.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@ \-\-with python2
.Ve
.PP
Aqui está como forçar o uso do sistema de compilação \fBModule::Build\fR do Perl, o qual pode ser necessário e o debhelper erradamente detectar que o pacote usa MakeMaker.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@ \-\-buildsystem=perl_build
.Ve
.PP
Aqui está um exemplo de criar uma sobreposição ao local onde os comandos \fBdh_auto_\fR\fI*\fR encontram a fonte do pacote, para um pacote cuja fonte está localizada num sub\-directório.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@ \-\-sourcedirectory=src
.Ve
.PP
E aqui está um exemplo de como dizer aos comandos \fBdh_auto_\fR\fI*\fR para compilarem num sub\-directório, o qual será removido em \fBclean\fR.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@ \-\-builddirectory=build
.Ve
.PP
Se o seu pacote poder ser compilado em paralelo, por favor use compatibilidade 10 ou passe \fB\-\-parallel\fR ao dh. Assim o \fBdpkg-buildpackage \-j\fR irá funcionar.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@ \-\-parallel
.Ve
.PP
Se o seu pacote não pode ser compilado correctamente usando múltiplos processos, por favor passe \fB\-\-no\-parallel\fR ao dh (ou ao comando \fBdh_auto_\fR\fI*\fR relevante):
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@ \-\-no\-parallel
.Ve
.PP
Aqui está um modo de prevenir que o \fBdh\fR corra vários comandos que você não quer que corram, ao definir alvos de sobreposição vazios para cada comando.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@
\&
\&        # Comandos a não correr:
\&        override_dh_auto_test override_dh_compress override_dh_fixperms:
.Ve
.PP
Pode-se separar um processo de compilação longo para um pacote de documentação separado usando sobreposições independentes da arquitectura. Estes serão saltados quando se corre as sequências build-arch e binary-arch.
.PP
.Vb 3
\&        #!/usr/bin/make \-f
\&        %:
\&                dh $@
\&
\&        override_dh_auto_build\-indep:
\&                $(MAKE) \-C docs
\&
\&        # Nenhum teste necessário para documentação
\&        override_dh_auto_test\-indep:
\&
\&        override_dh_auto_install\-indep:
\&                $(MAKE) \-C docs install
.Ve
.PP
Adicionando ao exemplo em cima, suponha que precisa de fazer chmod a um ficheiro, mas apenas quando compila o pacote dependente da arquitectura, pois ele não está presente quando compila apenas a documentação.
.PP
.Vb 3
\&        # Example assumes debhelper/12.8 and compat 10+
\&        execute_after_dh_fixperms\-arch:
\&                chmod 4755 debian/foo/usr/bin/foo
.Ve
.SH "ADDONS DH FORNECIDOS PELO DEBHELPER"
.IX Header "ADDONS DH FORNECIDOS PELO DEBHELPER"
O objetivo principal dos addons do \fBdh\fR é fornecer integração fácil com funcionalidades fornecidas por terceiros para o debhelper. No entanto, o próprio debhelper também fornece algumas sequências que podem ser úteis em alguns casos. Estas estão documentadas nesta lista:
.IP build-stamp 4
.IX Item "build-stamp"
Um addon especial para controlar se \fBdh\fR (em compatibilidade 10 ou posterior) irá criar ficheiros stamp para dizer se o alvo de compilação correu com sucesso. Veja "INTERNOS" para mais detalhes.
.Sp
Este addon está activo por predefinição mas pode ser desactivado ao usar \fBdh $@ \-\-without build-stamp\fR
.IP "dwz (obsoleto)" 4
.IX Item "dwz (obsoleto)"
Adiciona \fBdh_dwz\fR\|(1) à sequência em compatibilidade 11 ou inferior. Obsoleto compatibilidade 12 ou posterior.
.IP elf-tools 4
.IX Item "elf-tools"
Este addon adiciona ferramentas relativas a ficheiros ELF à sequência tal como \fBdh_strip\fR\|(1) e \fBdh_shlibdeps\fR\|(1)
.Sp
Este addon está activo \fIcondicionalmente\fR por predefinição para pacotes específicos de arquitectura \- isto é, é saltado para pacotes arch:all. Num caso especial que você precise destas ferramentas a funcionar em pacotes arch:all, você pode usar \fB\-\-with elf-tools\fR para o activar incondicionalmente.
.IP "installinitramfs (obsoleto)" 4
.IX Item "installinitramfs (obsoleto)"
Adiciona \fBdh_installinitramfs\fR\|(1) à sequência em compatibilidade 11 ou inferior. Obsoleto compatibilidade 12 ou posterior.
.IP "root-sequence (interno)" 4
.IX Item "root-sequence (interno)"
Isto está reservado para uso interno.
.IP single-binary 4
.IX Item "single-binary"
Um addon de objetivo-especial que faz o debhelper em modo "binário único".
.Sp
Quando activo, irá passar \fB\-\-destdir=debian/\fR\f(BIpackage\fR\fB/\fR ao \fBdh_auto_install\fR\|(1). Isto faz com que todos os ficheiros "instalados" pelo sistema de compilação do autor façam parte do (único) pacote binário por predefinição sem ter que se usar outros ajudantes como o \fBdh_install\fR\|(1).
.Sp
Como precaução o addon irá recusar activar-se quando o pacote fonte listar 2 ou mais pacotes binários em \fIdebian/control\fR.
.Sp
Antes da compatibilidade 15, este comportamento era o predefinido quando havia apenas um único pacote binário listado em \fIdebian/control\fR. Em compatibilidade 15 e posterior, este addon tem de ser activado explicitamente para que esta funcionalidade funcione.
.Sp
A razão para se requerer isto como uma escolha explícita é que se fosse implícita então o debhelper iria mudar o comportamento em silêncio ao se adicionar um novo pacote binário. Isto causou muitos bugs RC quando os maintainers renomeavam um binário e adicionavam pacotes de transição com a intenção de suportar actualizações perfeitas. O resultado era muitas vezes dois pacotes binários vazios que eram enviados para o arquivo com os utilizadores frustrados pois a sua "actualização" removeu os seus programas.
.IP "systemd (obsoleto)" 4
.IX Item "systemd (obsoleto)"
Adiciona \fBdh_systemd_enable\fR\|(1) e \fBdh_systemd_start\fR\|(1) à sequência em nível de compatibilidade 10 ou inferior. Obsoleto em compatibilidade 11 ou posterior.
.SH INTERNOS
.IX Header "INTERNOS"
Se você está curioso sobre o funcionamento interno do \fBdh\fR, aqui está como funciona por baixo da capota.
.PP
No modo compatibilidade 10 (ou posterior), o \fBdh\fR cria um ficheiro stamp <debian/debhelper\-build\-stamp> após os passo(s) de compilação estarem completos para evitar voltar a corre-los. É possível evitar o ficheiro stamp ao passar \fB\-\-without=build\-stamp\fR para  \fBdh\fR.  Isto faz com que compilações "não limpas" se comportem mais como o que algumas pessoas esperam à custa de possivelmente correrem a compilação e testa-la duas vezes (a segunda vez como root ou sob \fBfakeroot\fR\|(1)).
.PP
Dentro de um alvo de sobreposição, os comandos \fBdh_*\fR irão criar um ficheiro de registo \fIdebian/package.debhelper.log\fR para manter acompanhamento de para quais pacotes os comando(s) têm corrido. Estes ficheiros log são depois removidos assim que o alvo de sobreposição estiver completo.
.PP
No modo de compatibilidade 9 e anteriores, cada comando do debhelper irá gravar em \fIdebian/pacote.debhelper.log\fR quando é corrido com sucesso. (O qual \fBdh_clean\fR apaga.) Portanto o \fBdh\fR consegue dizer quais comandos já foram corridos, para quais pacotes, e evita correr esses comandos de novo.
.PP
De cada vez que \fBdh\fR corre (no nível de compatibilidade 9 ou anterior), examina o relatório, e encontra o último comando registado que está na sequência especificada. Depois continua com o próximo comando da sequência.
.PP
Uma sequência também pode correr alvos dependentes em debian/rules. Por exemplo, a sequência "binary" corre o alvo "install".
.PP
\&\fBdh\fR usa a variável de ambiente \fBDH_INTERNAL_OPTIONS\fR para passar informação através dos comandos debhelper que são corridos dentro de alvos de sobreposição. O conteúdo (e de facto a existência) desta variável de ambiente. como o nome sugere, está sujeito a alterações em qualquer altura.
.PP
Aos comandos nas sequências \fBbuild-indep\fR, \fBinstall-indep\fR e \fBbinary-indep\fR é passada a opção \fB\-i\fR para assegurar que eles apenas trabalham em pacotes independentes da arquitectura, e aos comandos nas sequências \fBbuild-arch\fR, \fBinstall-arch\fR e \fBbinary-arch\fR é passada a opção \fB\-a\fR para assegurar que eles apenas trabalham em pacotes dependentes da arquitectura.
.SH "VEJA TAMBÉM"
.IX Header "VEJA TAMBÉM"
\&\fBdebhelper\fR\|(7)
.PP
Este programa é parte do debhelper.
.SH AUTOR
.IX Header "AUTOR"
Joey Hess <joeyh@debian.org>
.SH TRADUÇÃO
.IX Header "TRADUÇÃO"
Américo Monteiro
.PP
Se encontrar algum erro na tradução deste documento, por favor comunique para
Américo Monteiro \fIa_monteiro@gmx.com\fR
ou
Equipa Debian de Tradução Portuguesa \fItraduz@debianpt.org\fR.