dpkg-maintscript-helper - Online na nuvem

PROGRAMA:

NOME

dpkg-maintscript-helper - contorna as limitações conhecidas do dpkg em scripts de mantenedor

SINOPSE

dpkg-maintscript-helper comando [parâmetro...] -- parâmetro de script de manutenção...

COMANDOS E PARÂMETROS

suporta comando

rm_conffile arquivo de configuração [versão anterior [pacote]]

mv_conffile velho conffile novo-conffile [versão anterior [pacote]]

link simbólico_para_dir pathname alvo antigo [versão anterior [pacote]]

dir_to_symlink pathname novo alvo [versão anterior [pacote]]

DESCRIÇÃO

Este programa é projetado para ser executado dentro de scripts de mantenedor para realizar algumas tarefas que
dpkg não pode (ainda) lidar nativamente por causa das decisões de design ou devido a
limitações.

Muitas dessas tarefas requerem ações coordenadas de vários scripts de mantenedor (pré-instalar,
postinst, prematuro, postrm) Para evitar erros, a mesma chamada simplesmente precisa ser colocada em todos
scripts e o programa irá adaptar automaticamente seu comportamento com base no ambiente
variável DPKG_MAINTSCRIPT_NAME e nos argumentos dos scripts do mantenedor que você deve
forward após um hífen duplo.

COMUM PARÂMETROS

versão anterior
Define a versão mais recente do pacote cuja atualização deve acionar o
Operação. É importante calcular versão anterior corretamente para que o
as operações são realizadas corretamente, mesmo se o usuário reconstruir o pacote com um
versão local. Se versão anterior está vazio ou omitido, então a operação é tentada
a cada atualização (nota: é mais seguro fornecer a versão e tentar a operação
apenas uma vez).

Se o conffile não foi enviado para várias versões, e agora você está
modificar os scripts do mantenedor para limpar o arquivo obsoleto, versão anterior
deve ser baseado na versão do pacote que você está preparando agora, não no
primeira versão do pacote que não tinha o conffile. Isso se aplica a todos os outros
ações da mesma maneira.

Por exemplo, para um conffile removido na versão 2.0-1 de um pacote, versão anterior
deve ser definido para 2.0-1 ~. Isso fará com que o conffile seja removido, mesmo que o
usuário reconstruiu a versão anterior 1.0-1 as 1.0-1local1. Ou um pacote trocando um
caminho de um link simbólico (enviado na versão 1.0-1) para um diretório (enviado na versão
2.0-1), mas apenas realizando a troca real nos scripts do mantenedor na versão
3.0-1, deve definir versão anterior para 3.0-1 ~.

pacote
O nome do pacote. Quando o pacote é “Multi-Arch: mesmo” este parâmetro deve
incluir o qualificador de arquitetura, caso contrário, deve não geralmente incluem o
qualificador de arquitetura (uma vez que não permitiria classificações cruzadas, ou a mudança de ser
arquitetura específica para arquitetura todos os ou vice-versa). Se o parâmetro for
vazio ou omitido, o DPKG_MAINTSCRIPT_PACKAGE e DPKG_MAINTSCRIPT_ARCH
variáveis ​​de ambiente (conforme definido por dpkg) será usado para gerar um arqui-qualificado
nome do pacote.

-- Todos os parâmetros dos scripts do mantenedor devem ser encaminhados ao programa
depois de --.

CONFILE ΣΧΕΤΙΖΕΤΑΙ TAREFAS

Ao atualizar um pacote, dpkg não irá remover automaticamente um conffile (uma configuração
arquivo para o qual dpkg deve preservar as alterações do usuário) se não estiver presente no mais recente
versão. Existem duas razões principais para isso; a primeira é que o conffile poderia ter
foi descartado por acidente e a próxima versão poderia restaurá-lo, os usuários não iriam querer seu
mudanças jogadas fora. A segunda é permitir que os pacotes façam a transição de arquivos de um
O conffile mantido pelo dpkg para um arquivo mantido pelos scripts do mantenedor do pacote, geralmente
com uma ferramenta como debconf ou ucf.

Isso significa que se um pacote pretende renomear ou remover um arquivo de configuração, ele deve
faça isso explicitamente e dpkg-maintscript-helper pode ser usado para implementar a exclusão normal
e movimentação de conffiles dentro dos scripts do mantenedor.

remoção a arquivo de configuração
Se um arquivo de arquivo for completamente removido, ele deve ser removido do disco, a menos que o usuário
modificou. Se houver modificações locais, elas devem ser preservadas. Se o pacote
atualizações abortam, o conffile recém-obsoleto não deve desaparecer.

Tudo isso é implementado colocando o seguinte snippet de shell no pré-instalar, postinst
e postrm scripts de mantenedor:

dpkg-maintscript-helper rm_conffile\
arquivo de configuração versão anterior pacote - "$ @"

arquivo de configuração é o nome do arquivo do arquivo de configuração a ser removido.

Implementação atual: no pré-instalar, ele verifica se o conffile foi modificado e renomeia
tanto para arquivo de configuração.dpkg-remove (se não for modificado) ou para arquivo de configuração.dpkg-backup (E se
modificado). No postinst, o último arquivo é renomeado para arquivo de configuração.dpkg-bak e guardado por
referência, pois contém modificações do usuário, mas o anterior será removido. Se o pacote
a atualização aborta, o postrm reinstala o conffile original. Durante a purga, o postrm precisarão
também exclua o .dpkg-bak arquivo mantido até agora.

Renomeando a arquivo de configuração
Se um arquivo de arquivo for movido de um local para outro, você precisa se certificar de que se desloca
quaisquer alterações que o usuário tenha feito. Isso pode parecer uma mudança simples para o pré-instalar script em
primeiro, no entanto, isso resultará na solicitação do usuário por dpkg aprovar o conffile
edições, embora eles não sejam responsáveis ​​por eles.

A renomeação elegante pode ser implementada colocando o seguinte snippet de shell no
pré-instalar, postinst e postrm scripts de mantenedor:

dpkg-maintscript-helper mv_conffile \
velho conffile novo-conffile versão anterior pacote - "$ @"

velho conffile e novo-conffile são o antigo e o novo nome do conffile a ser renomeado.

Implementação atual: o pré-instalar verifica se o conffile foi modificado, se sim é
deixado no lugar, caso contrário, ele é renomeado para velho conffile.dpkg-remove. Na configuração, o
postinst remove velho conffile.dpkg-remove e renomeia velho conffile para novo-conffile if velho-
arquivo de configuração Ainda está disponível. Em abort-upgrade / abort-install, o postrm renomeia velho-
arquivo de configuração.dpkg-remove voltar para velho conffile se necessário.

LINK SIMBÓLICO E DIRETÓRIO COMUTA

Ao atualizar um pacote, dpkg não mudará automaticamente um link simbólico para um diretório ou
vice-versa. Downgrades não são suportados e o caminho será deixado como está.

Mudar a ligação simbólica para anuário
Se um link simbólico for mudado para um diretório real, você precisa ter certeza antes de descompactar isso
o link simbólico é removido. Isso pode parecer uma mudança simples para o pré-instalar script em primeiro lugar,
no entanto, isso resultará em alguns problemas no caso de personalização local do administrador do
link simbólico ou ao fazer o downgrade do pacote.

A renomeação elegante pode ser implementada colocando o seguinte snippet de shell no
pré-instalar, postinst e postrm scripts de mantenedor:

dpkg-maintscript-helper symlink_to_dir\
pathname alvo antigo versão anterior pacote - "$ @"

pathname éo nome absoluto do link simbólico antigo (o caminho será um diretório no final
da instalação) e alvo antigo é o nome de destino do antigo link simbólico em pathname.
Pode ser absoluto ou relativo ao diretório que contém pathname.

Implementação atual: o pré-instalar verifica se o link simbólico existe e aponta para alvo antigo,
se não, ele é deixado no lugar, caso contrário, é renomeado para pathname.dpkg-backup. Em
configuração, o postinst remove pathname.dpkg-backup if pathname.dpkg-backup ainda é
um link simbólico. Em abort-upgrade / abort-install, o postrm renomeia pathname.dpkg-backup voltar para
pathname se necessário.

Mudar a anuário para ligação simbólica
Se um diretório real for alterado para um link simbólico, você precisa ter certeza antes de descompactar isso
o diretório é removido. Isso pode parecer uma mudança simples para o pré-instalar script em primeiro lugar,
no entanto, isso resultará em alguns problemas caso o diretório contenha arquivos de configuração,
nomes de caminhos pertencentes a outros pacotes, nomes de caminhos criados localmente ou ao fazer o downgrade do
pacote.

A comutação normal pode ser implementada colocando o seguinte snippet de shell no
pré-instalar, postinst e postrm scripts de mantenedor:

dpkg-maintscript-helper dir_to_symlink\
pathname novo alvo versão anterior pacote - "$ @"

pathname éo nome absoluto do diretório antigo (o caminho será um link simbólico no final
da instalação) e novo alvo é o alvo do novo link simbólico em pathname. Pode
seja absoluto ou relativo ao diretório que contém pathname.

Implementação atual: o pré-instalar verifica se o diretório existe, não contém
conffiles, nomes de caminhos pertencentes a outros pacotes, ou nomes de caminhos criados localmente, se não então
é deixado no lugar, caso contrário, é renomeado para pathname.dpkg-backup, e uma encenação vazia
diretório chamado pathname é criado, marcado com um arquivo para que o dpkg possa rastreá-lo. Sobre
configuração, o postinst termina a troca se pathname.dpkg-backup ainda é um
diretório e pathname é o diretório temporário; remove a marca do diretório de teste
arquivo, move os arquivos recém-criados dentro do diretório de teste para o destino do link simbólico
novo alvo/, substitui o diretório de teste agora vazio pathname com um link simbólico para Novo-
alvo, e remove pathname.dpkg-backup. Em abort-upgrade / abort-install, o postrm
renomeia pathname.dpkg-backup voltar para pathname se necessário.

INTEGRAÇÃO IN KITS

Ao usar um auxiliar de empacotamento, verifique se ele possui dpkg-maintscript-helper
integração, o que pode facilitar sua vida. Veja por exemplo dh_installdeb(1).

Dado que dpkg-maintscript-helper é usado no pré-instalar, usando-o incondicionalmente
requer uma pré-dependência para garantir que a versão necessária do dpkg foi desempacotado
antes. A versão necessária depende do comando usado, para rm_conffile e mv_conffile
é 1.15.7.2, para link simbólico_para_dir e dir_to_symlink é 1.17.14:

Pré-Dependências: 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, podemos chamar o programa apenas se soubermos que o
o comando necessário é suportado pelo atualmente instalado dpkg:

se dpkg-maintscript-helper suportar comando; então
dpkg-maintscript-helper comando ...
fi

O comando suporta retornará 0 em caso de sucesso, 1 caso contrário. o suporta comando vai
verifique se as variáveis ​​de ambiente definidas pelo dpkg e exigidas pelo script estão presentes,
e irá considerá-lo uma falha caso o ambiente não seja suficiente.

Use dpkg-maintscript-helper online usando serviços onworks.net