.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.40)
.\"
.\" 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
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    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 "2021-03-06" "13.3.4" "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
\&\*(L"Sobrepor um comando\*(R" 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. 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"
Se você desejar confirmar que o \fBdh\fR viu um alvo de sobreposição ou hook,
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 \*(L"Alvos completamente vazios\*(R" 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 \*(L"corpo\*(R" 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 \fB\s-1SIMPLE\s0\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 \fI\s-1PROGRAMMING\s0\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 "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 corrê\-los. É possível evitar o ficheiro stamp
ao passar \fB\-\-without=build\-stamp\fR para  \fBdh\fR.  Isto faz com que
compilações \*(L"não limpas\*(R" se comportem mais como o que algumas pessoas
esperam à custa de possivelmente correrem a compilação e testá\-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 \*(L"binary\*(R" corre o alvo \*(L"install\*(R".
.PP
\&\fBdh\fR usa a variável de ambiente \fB\s-1DH_INTERNAL_OPTIONS\s0\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.