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.
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~.
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.
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.
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.
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.
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.
Dado que dpkg-maintscript-helper é usado no preinst, usá-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.
Se encontrar algum erro na tradução deste documento, por favor comunique para Américo Monteiro <a_monteiro@gmx.com>.