dpkg-maintscript-helper Man page

dpkg-maintscript-helper suite dpkg dpkg-maintscript-helper

NOM
dpkg-maintscript-helper – contournement des limitations connues de dpkg
dans les scripts du responsable

SYNOPSIS

dpkg-maintscript-helper commande [paramètres…] —
paramètres-script-responsable…

COMMANDES ET PARAMÈTRES
supports commande

rm_conffile fichier-de-configuration [version-précédente [paquet]]

mv_conffile ancien-fichier-de-configuration nouveau-fichier-de-configu‐
ration [dernière-version [paquet]]

symlink_to_dir nom-de-chemin ancienne-cible [version-précédente
[paquet]]

dir_to_symlink nom-de-chemin nouvelle-cible [version-précédente
[paquet]]

DESCRIPTION

Ce programme est prévu pour être exécuté dans les scripts du respon‐
sable afin de réaliser certaines tâches que dpkg ne peut pas (encore)
prendre en charge directement à cause de limites de conception ou de
limitations actuelles.

La plupart de ces tâches nécessitent la coordination de plusieurs
scripts du responsable (preinst, postinst, prerm, postrm). Pour éviter
des erreurs, le même appel a simplement besoin d’être placé dans tous
les scripts. Le programme adaptera alors son comportement en fonction
de la variable d’environnement DPKG_MAINTSCRIPT_NAME et des paramètres
des scripts du responsable qui doivent être passés avec un double
tiret.

PARAMÈTRES COMMUNS
version-précédente
Indique la dernière version du paquet pour laquelle la mise à
jour doit provoquer l’opération. Il est important de déterminer
correctement version-précédente afin que les opérations s’accom‐
plissent correctement même si l’utilisateur reconstruit le
paquet avec une version locale. Si le paramètre version-précé‐
dente est vide ou omis, l’opération sera tentée à chaque mise à
jour (il est toutefois plus sûr d’indiquer la version afin que
l’opération n’ait lieu qu’une fois).

Si le fichier de configuration n’était pas fourni pour une rai‐
son ou une autre dans plusieurs versions et que vous modifiez
les scripts du responsable pour nettoyer l’ancien fichier, ver‐
sion-précédente doit être basé sur la version actuellement pré‐
parée et non la première version qui ne fournissait plus ce
fichier de configuration. Ceci s’applique à toutes les autres
actions de la même manière

Par exemple, pour un fichier de configuration supprimé dans la
version 2.0-1 d’un paquet, dernière-version doit être 2.0-1~.
Cela provoquera la suppression du fichier même si la version
précédente 1.0-1 a été reconstruite avec 1.0-1local1 comme
numéro de version. Ou bien, si un paquet substitue un chemin
d’un lien symbolique (fourni dans la version 1.0-1) à un réper‐
toire (fourni dans la version 2.0-1), mais ne réalise réellement
la substitution que dans les scripts du responsable dans la ver‐
sion 3.0-1, dernière-version doit être 3.0-1~.

paquet The package name. When the package is “Multi-Arch: same” this
parameter must include the architecture qualifier, otherwise it
should not usually include the architecture qualifier (as it
would disallow cross-grades, or switching from being architec‐
ture specific to architecture all or vice versa). If the parame‐
ter is empty or omitted, the DPKG_MAINTSCRIPT_PACKAGE and
DPKG_MAINTSCRIPT_ARCH environment variables (as set by dpkg)
will be used to generate an arch-qualified package name.

— Tous les paramètres des scripts du responsable doivent être pas‐
sés au programme après –.

TÂCHES LIÉES AUX FICHIERS DE CONFIGURATION
Lors de la mise à jour d’un paquet, dpkg ne supprime pas automatique‐
ment les fichiers de configuration (comportant des modifications
locales à préserver) s’il n’est pas présent dans la nouvelle version.
Il existe deux raisons principales à cela. En premier lieu, le fichier
de configuration peut avoir été supprimé par accident, être réintégré
dans la version suivante et il peut être nécessaire de retrouver les
modifications locales. Ensuite, l’objectif est également de permettre
d’effectuer la transition depuis des fichiers de configuration gérés
par dpkg vers un fichier géré via les scripts du responsable, en géné‐
ral à l’aide d’un outil comme debconf ou ucf.

Cela signifie que si un paquet a besoin de renommer ou supprimer un
fichier de configuration, il doit le faire explicitement. L’objectif de
dpkg-maintscript-helper est donc de fournir des méthodes de suppression
ou renommage de fichiers de configuration via les scripts du respon‐
sable.

Supprimer un fichier de configuration
Si un fichier de configuration est complètement supprimé, il doit être
effacé du disque sauf si l’administrateur local l’a modifié. Les éven‐
tuelles modifications locales doivent être conservées. Si la mise à
jour du paquet est interrompue, le fichier de configuration rendu obso‐
lète ne doit pas avoir disparu.

L’ensemble de ces pré-requis est mis en ?uvre en utilisant les com‐
mandes shell suivantes dans les scripts preinst, postinst et postrm :

dpkg-maintscript-helper rm_conffile \
fichier-de-configuration dernière-version paquet — “$@”

fichier-de-configuration est le nom du fichier de configuration à sup‐
primer.

Détails de la mise en ?uvre actuelle : dans le script preinst, il est
vérifié si le fichier de configuration a été modifié. Celui-ci est
alors renommé, soit en fichier-de-configuration.dpkg-remove s’il n’a
pas été modifié, soit en fichier-de-configuration.dpkg-backup s’il l’a
été. Dans le script postinst, ce dernier fichier est ensuite renommé en
fichier-de-configuration.dpkg-bak et conservé pour référence puisqu’il
contient des modifications locales, mais le premier est supprimé. Si la
mise à jour du paquet est interrompue, le script postrm remet en place
le fichier de configuration d’origine. À la purge du paquet, le script
postrm supprimera également le fichier .dpkg-bak qui avait été conservé
jusque là.

Renommer un fichier de configuration
Si un fichier de configuration est déplacé à un autre endroit, il est
nécessaire de garantir la préservation des modifications locales. À
première vue, cela peut sembler être une simple modification dans le
script preinst, mais cela risque de résulter en une demande, par dpkg,
d’approbation de modifications locales qui n’existent pas réellement.

Un renommage élégant peut être mis en ?uvre avec les extraits shell qui
suivent, dans les scripts preinst, postinst et postrm :

dpkg-maintscript-helper mv_conffile \

ancien-fichier et nouveau-fichier sont l’ancien et le nouveau nom du
fichier de configuration à renommer.

Détails de la mise en ?uvre actuelle : dans le script preinst, il est
vérifié si le fichier de configuration a été modifié. Celui-ci est
alors soit laissé en place s’il a été modifié, soit renommé en
ancien-fichier.dpkg-remove s’il ne l’a pas été. Lors de la configura‐
tion, le script postinst supprime ancien-fichier.dpkg-remove et renomme
ancien-fichier et nouveau-fichier si ancien-fichier existe toujours. Si
la mise à jour ou l’installation sont interrompues, le script postrm
renomme ancien-fichier.dpkg-remove en ancien-fichier si c’est indispen‐
sable.

SUBSTITUTIONS DE LIENS SYMBOLIQUES ET DE RÉPERTOIRES
Lors de la mise à jour d’un paquet, dpkg ne substitue pas automatique‐
ment un lien symbolique à un répertoire ou le contraire. Les retours à
une version inférieure ne sont pas pris en charge et le chemin sera
laissé comme il est.

Substituer un lien symbolique à un répertoire
Si un lien symbolique est substitué à un répertoire réel, il est néces‐
saire de garantir qu’avant le dépaquettage le lien symbolique est
retiré. À première vue, cela peut sembler être une simple modification
dans le script preinst, mais cela risque de résulter en problèmes si
l’administrateur local a personnalisé le lien symbolique ou si l’on
revient à une version antérieure du paquet.

Un renommage élégant peut être mis en ?uvre avec les extraits shell qui
suivent, dans les scripts preinst, postinst et postrm :

dpkg-maintscript-helper symlink_to_dir \
nom-de-chemin ancienne-cible version-précédente paquet — “$@”

nom-de-chemin est le nom absolu de l’ancien lien symbolique (le chemin
sera un répertoire à la fin de l’installation) et ancienne-cible la
cible de l’ancien lien symbolique vers nom-de-chemin. Cela peut être un
chemin absolu ou relatif vers le répertoire contenant nom-de-chemin.

Détails de la mise en ?uvre actuelle : dans le script preinst, il est
vérifié si le lien symbolique existe et pointe vers ancienne-cible. Si
ce n’est pas le cas, il est alors soit laissé en place, soit renommé en
nom-de-chemin.dpkg-backup. Lors de la configuration, le script postinst
supprime nom-de-chemin.dpkg-backup si nom-de-chemin.dpkg-backup est
encore un lien symbolique. Si la mise à jour ou l’installation sont
interrompues, le script postrm renomme nom-de-chemin.dpkg-backup en
nom-de-chemin si c’est indispensable.

Substituer un répertoire à un lien symbolique
Si un répertoire réel est substitué à un lien symbolique, il est néces‐
saire de garantir qu’avant le dépaquettage le répertoire est retiré. À
première vue, cela peut sembler être une simple modification dans le
script preinst, mais cela risque de résulter en problèmes si le réper‐
toire contient des fichiers de configuration, des noms de chemins qui
appartiennent à d’autres paquets, des noms de chemin créés localement
ou si l’on revient à une version antérieure du paquet.

Une substitution élégante peut être mise en ?uvre avec les extraits
shell qui suivent, dans les scripts preinst, postinst et postrm :

dpkg-maintscript-helper dir_to_symlink \
nom-de-chemin nouvelle-cible version-précédente paquet — “$@”

nom-de-chemin est le nom absolu de l’ancien répertoire (le chemin sera
un lien symbolique à la fin de l’installation) et nouvelle-cible la
cible du nouveau lien symbolique vers nom-de-chemin. Cela peut être un
chemin absolu ou relatif vers le répertoire contenant nom-de-chemin.

Détails de la mise en ?uvre actuelle : dans le script preinst, il est
vérifié si le répertoire existe et ne contient pas de fichiers de
configuration, de noms de chemins qui appartiennent à d’autres paquets,
de noms de chemin créés localement. Si ce n’est pas le cas, il est
alors soit laissé en place, soit renommé en nom-de-chemin.dpkg-backup
et un répertoire vide provisoire nommé nom-de-chemin est créé, marqué
par un fichier pour que dpkg le suive. Lors de la configuration, le
script postinst achève la substitution si nom-de-chemin.dpkg-backup
est encore un répertoire et si nom-de-chemin est le répertoire provi‐
soire. Il supprime le fichier qui marque le fichier provisoire et
déplace les fichiers nouvellement créés dans le répertoire provisoire
vers la cible du lien symbolique nouvelle cible, remplace le répertoire
provisoire nom-de-chemin, maintenant vide, par un lien symbolique vers
la nouvelle-cible et, enfin supprime nom-de-chemin.dpkg-backup. Si la
mise à jour ou l’installation sont interrompues, le script postrm
renomme nom-de-chemin.dpkg-backup en nom-de-chemin si c’est indispen‐
sable.

INTÉGRATION DANS LES PAQUETS
Lors de l’utilisation d’un assistant d’empaquetage, veuillez vérifier
s’il ne dispose pas d’une intégration native de dpkg-maintscript-helper
ce qui vous facilitera la tâche. Voir par exemple dh_installdeb(1).

Comme dpkg-maintscript-helper est utilisé dans le script preinst,
l’utiliser sans conditions impose une pré-dépendance afin de garantir
que la version minimale nécessaire de dpkg ait bien été préalablement
configurée. La version minimale dépend de la commande utilisée : ainsi
pour rm_conffile et mv_conffile, cette version est 1.15.7.2, pour sym‐
link_to_dir et dir_to_symlink, c’est 1.17.14 :

Pre-Depends: dpkg (>= 1.17.14)

Cependant, dans de nombreux cas, l’opération réalisée par le programme
n’est pas critique pour le paquet et au lieu d’utiliser une pré-dépen‐
dance, il est possible de ne lancer le programme que si on a la certi‐
tude que la commande nécessaire est gérée par la version actuellement
installée de dpkg :

if dpkg-maintscript-helper supports commande; then
dpkg-maintscript-helper commande …
fi

La commande supports retournera 0 en cas de réussite, 1 autrement.
Elle vérifiera si les variables d’environnement telles que définies par
dpkg et requises par le script sont présentes, et considérera que c’est
un échec si l’environnement n’est pas suffisant.

VOIR AUSSI
dh_installdeb(1)

TRADUCTION
Ariel VARDI , 2002. Philippe Batailler, 2006.
Nicolas François, 2006. Veuillez signaler toute erreur à
.

Projet Debian 01-09-2014 dpkg-maintscript-helper