Provided by: dpkg_1.22.6ubuntu6.1_amd64 bug

NOME

       dpkg-maintscript-helper - contorna limitações conhecidas do dpkg em scripts de maintainer.

RESUMO

       dpkg-maintscript-helper command [parameter...] -- maint-script-parameter...

COMANDOS E PARÂMETROS

       supports command
       rm_conffile conffile [prior-version [package]]
       mv_conffile old-conffile new-conffile [prior-version [package]]
       symlink_to_dir pathname old-target [prior-version [package]]
       dir_to_symlink pathname new-target [prior-version [package]]

DESCRIÇÃO

       Este programa destina-se a ser corrido dentro de scripts de maintainer para conseguir
       algumas tarefas que o dpkg (ainda) não pode lidar nativamente seja por limitações de
       desenho ou devido a limitações actuais,

       Muitas destas tarefas requerem acções coordenadas dos vários scripts de maintainer
       (preinst, postinst, prerm, postrm). Para evitar enganos a mesma chamada precisa
       simplesmente de englobar todos os scripts e o programa irá automaticamente adaptar o seu
       comportamento baseado na variável de ambiente DPKG_MAINTSCRIPT_NAME e nos argumentos dos
       scripts do maintainer que você tem de reencaminhar após um duplo hífen.

       Este programa foi introduzido no dpkg 1.15.7.

PARÂMETROS COMUNS

       prior-version
           Define a versão mais recente do pacote cuja actualização deverá despoletar a operação.
           É importante calcular prior-version correctamente para que as operações sejam
           correctamente executadas mesmo que o utilizador recompile o pacote com uma versão
           local. Se prior-version estiver vazio ou omitido, então a operação é tentada a cada
           actualização (nora: é mais seguro fornecer a versão e ter a operação tentada apenas
           uma vez).

           Se o conffile não tem sido enviado por várias versões, e você está agora a modificar
           os scripts do maintainer para limpar o ficheiro obsoleto, prior-version deve ser
           baseado na versão do pacote que está agora a preparar, e não a primeira versão do
           pacote onde faltou o conffile. Isto aplica-se a todas as outras acções do mesmo modo.

           Por exemplo, para um conffile removido na versão 2.0-1 de um pacote, prior-version
           deve ser definido para 2.0-1~. Isto irá fazer com que o conffile seja removido mesmo
           que o utilizador recompile a versão anterior 1.0-1 como 1.0-1local1. Ou um pacote que
           mude um caminho de um link simbólico (enviado na versão  1.0-1) para um directório
           (enviado na versão 2.0-1), mas apenas executando a mudança real nos scripts do
           maintainer na versão 3.0-1, deve definir prior-version para 3.0-1~.

       package
           O nome do pacote que possui os nome(s) de caminho(s). Quando o pacote é “Multi-Arch:
           same” este parâmetros tem de incluir o qualificador de arquitectura, caso contrário
           não deverá geralmente incluir o qualificador de arquitectura ((pois iria desautorizar
           cruzamento de graduação, ou comutar de ser específico de arquitectura para
           arquitectura all ou vice versa). Se o parâmetro estiver vazio ou omitido, as variáveis
           de ambiente DPKG_MAINTSCRIPT_PACKAGE e DPKG_MAINTSCRIPT_ARCH (definidas pelo dpkg ao
           correr os scripts do maintainer) serão usadas para gerar um nome de pacote com
           qualificação de arquitectura.

       --  Todos os parâmetros dos scripts do maintainer têm de ser encaminhados ao programa após
           --.

TAREFAS RELACIONADAS COM FICHEIROS DE CONFIGURAÇÃO

       Ao actualizar um pacote, o dpkg não irá automaticamente remover um conffile (um ficheiro
       de configuração para o qual dpkg deve preservar as alterações do utilizador) se este não
       estiver presente na versão mais recente. Existem duas razões principais para isto: a
       primeira é que o conffile poderia ser abandonado por acidente e a próxima versão poderia
       restaura-lo., e os utilizadores não querem que as suas alterações sejam deitadas fora. A
       segunda é para permitir aos pacotes transitarem ficheiros de um conffile mantido pelo dpkg
       para um ficheiro mantido pelos scripts do maintainer do pacote, geralmente com uma
       ferramenta como debconf ou ucf.

       Isto significa que se um pacote se destina a renomear ou remover um conffile, deve
       explicitamente fazê-lo e dpkg-maintscript-helper pode ser usado para implementar o apagar
       e mover elegante de conffiles dentro dos scripts do maintainer.

   Remover um ficheiro de configuração
       Nota: Isto pode ser substituído na maioria dos casos pela bandeira "remove-on-upgrade" em
       DEBIAN/conffiles (desde dpkg 1.20.6), veja deb-conffiles(5).

       Se um conffile for completamente removido, deve ser removido do disco, a menos que o
       utilizador o tenha modificado. Se existirem modificações locais, estas devem ser
       preservadas. Se a actualização do pacote abortar, o conffile obsoleto mais recente não
       deve desaparecer.

       tudo isto é implementado ao colocar o seguinte fragmento de shell nos scripts de
       maintainer preinst, postinst e postrm:

            dpkg-maintscript-helper rm_conffile \
               conffile prior-version package -- "$@"

       conffile é o nome de ficheiro do conffile a remover.

       Implementação actual: no preinst, verifica se o conffile foi modificado e renomeia-o ou
       para conffile.dpkg-remove (se não modificado) ou para conffile.dpkg-backup (se
       modificado). No postinst, o último ficheiro é renomeado para conffile.dpkg-bak e mantido
       para referência pois contem modificações do utilizador mas o antigo será removido. Se a
       actualização ao pacote abortar, o postrm reinstala o conffile original. Durante a purga, o
       postrm irá também apagar o ficheiro .dpkg-bak mantido até à data.

   Renomear um conffile
       Se um conffile for movido de uma localização para outra, você precisa de certificar que se
       move por quaisquer alterações que o utilizador tenha feito. Isto pode parecer uma mudança
       simples para o script preinst no inicio, no entanto isso vai resultar no utilizador a ser
       questionado pelo dpkg para aprovar as edições no conffile mesmo este não sendo o
       responsável por elas.

       O renomear elegante pode ser implementado ao colocar o seguinte fragmente do shell nos
       scripts de maintainer preinst, postinst e postrm:

            dpkg-maintscript-helper mv_conffile \
               old-conffile new-conffile prior-version package -- "$@"

       old-conffile e new-conffile sãos os nomes antigo e novo do conffile a renomear.

       Implementação actual: o preinst verifica se o conffile foi modificado. Se sim, é deixado
       no lugar, caso contrário é renomeado para old-conffile.dpkg-remove. Durante a
       configuração, o postinst remove old-conffile.dpkg-remove e renomeia old-conffile para new-
       conffile se old-conffile ainda estiver disponível. No
       abortar-actualização/abortar-instalação, o postrm renomeia old-conffile.dpkg-remove de
       volta a old-conffile se necessário.

LINKS SIMBÓLICOS E SWITCHES DE DIRECTÓRIO

       Ao actualiza um pacote, o dpkg não irá mudar automaticamente de um link simbólico para um
       directório ou vice-versa. Downgrades (descidas de versão) não são suportados e o caminho
       irá ser deixado como está.

       Nota: Os links simbólicos e directórios criados durante esses switches precisam de ser
       enviados nos novos pacotes, ou o dpkg não será capaz de os remover durante a purga.

   Alternar um link simbólico para directório
       Se um link simbólico for mudado para um directório real, você precisa de certificar que o
       link simbólico é removido antes de desempacotar. Isto pode parecer uma mudança simples
       para o script preinst no inicio, no entanto isso irá resultar em alguns problemas no caso
       de personalização local administrativa do link simbólico ou quando se retrocede na versão
       do pacote (downgrade).

       O renomear elegante pode ser implementado ao colocar o seguinte fragmente do shell nos
       scripts de maintainer preinst, postinst e postrm:

            dpkg-maintscript-helper symlink_to_dir \
               pathname old-target prior-version package -- "$@"

       pathname é o nome absoluto do link simbólico antigo (o caminho será um directório no final
       da instalação) e old-target é o nome do alvo do link simbólico anterior em pathname. Pode
       ser ou absoluto ou relativo ao directório que contem pathname.

       Implementação actual: o preinst verifica se o link simbólico existe e aponta para old-
       target, se não então deixa-o como estiver, caso contrário é renomeado para
       pathname.dpkg-backup. Na configuração, o postinst remove pathname.dpkg-backup se
       pathname.dpkg-backup for ainda um link simbólico. Ao aborta actualização/instalação. o
       postrm renomeia <pathname>.dpkg-backup de volta para pathname se necessário.

   Alternar um directório para link simbólico
       Se um directório é comutado para um link simbólico, você precisa de certificar-se antes de
       desempacotar que o directório foi removido. Isto pode parecer no início uma alteração
       simples ao script preinst, no entanto isso vai resultar em alguns problemas se o
       directório conter conffiles, nomes de caminhos possuídos por outros pacotes, nomes de
       caminhos criados localmente, ou quando instala uma versão anterior do pacote (downgrade).

       Mudança elegante pode ser implementada ao colocar o seguinte fragmento de shell nos
       scripts preinst, postinst e postrm do maintainer:

            dpkg-maintscript-helper dir_to_symlink \
               pathname new-target prior-version package -- "$@"

       pathname é o nome absoluto do directório antigo (o caminho será um link simbólico no final
       da instalação) e new-target é o alvo do novo link simbólico em pathname. Pode ser ou
       absoluto ou relativo ao directório que contem pathname.

       Implementação actual: o preinst verifica se o directório existe, não contém conffiles,
       nomes de caminhos possuídos por outros pacotes, ou nomes de caminhos criados localmente,
       se não então é deixa-do como está, caso contrário é renomeado para pathname.dpkg-backup, e
       é criado um directório vazio estagiário chamado pathname, marcado com um ficheiro para que
       o dpkg o possa acompanhar. Na configuração, o postinst termina a comutação se
       pathname.dpkg-backup for ainda um directório e se pathname é o directório de estagiário;
       remove o ficheiro marcador do directório estagiário, move os ficheiros acabados de criar
       dentro do directório estagiário para o link simbólico alvo new-target/, substitui o agora
       vazio directório estagiário pathname com um link simbólico para new-target, e remove
       pathname.dpkg-backup. Ao abortar actualização/instalação, o postrm renomeia
       pathname.dpkg-backup de volta para pathname se necessário.

INTEGRAÇÃO EM PACOTES

       Quando usar um ajudante de empacotamento, por favor verifique se ele tem integração com
       dpkg-maintscript-helper nativa, o que pode tornar a sua vida mais fácil. Veja por exemplo
       dh_installdeb(1).

       Dado que dpkg-maintscript-helper é usado no preinst, usa-lo incondicionalmente requer uma
       pré-dependência para assegurar que a versão requerida do dpkg já foi desempacotada antes.
       A versão requerida depende do comando usado, para rm_conffile e mv_conffile é 1.15.7.2,
       para symlink_to_dir e dir_to_symlink é 1.17.14:

        Pre-Depends: dpkg (>= 1.17.14)

       Mas em muitos casos a operação feita pelo programa não é crítica para o pacote, e em vez
       de usar uma pré-dependência nós podemos chamar o programa apenas quando sabemos que o
       comando requerido é suportado pelo dpkg presentemente instalado:

            if dpkg-maintscript-helper supports command; then
               dpkg-maintscript-helper command ...
            fi

       O comando supports irá retornar 0 em sucesso, 1 caso contrário. O comando supports irá
       verificar se as variáveis de ambiente estão presentes como definidas pelo dpkg e
       requeridas pelo script, e irá considerar um fracasso no caso do ambiente não ser
       suficiente.

AMBIENTE

       DPKG_ROOT
           Se definido, será usado como o directório raiz do sistema de ficheiros.

       DPKG_ADMINDIR
           Se definido, será usado como o directório de dados do dpkg.

       DPKG_COLORS
           Define o modo de cor (desde dpkg 1.19.1). Os valores presentemente aceites são: auto
           (predefinição), always e never.

VEJA TAMBÉM

       dh_installdeb(1).

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>.