Provided by: dpkg_1.22.0ubuntu1.1_amd64 
NOM
dpkg-maintscript-helper - Contournement des limitations connues de dpkg dans les scripts
du responsable
SYNOPSIS
dpkg-maintscript-helper commande [paramètre...] -- paramètre-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-configuration
[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 responsable 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.
Many of those tasks require coordinated actions from several maintainer scripts (preinst,
postinst, prerm, postrm). To avoid mistakes the same call simply needs to be put in all
scripts and the program will automatically adapt its behavior based on the environment
variable DPKG_MAINTSCRIPT_NAME and on the maintainer scripts arguments that you have to
forward after a double hyphen.
This program was introduced in dpkg 1.15.7.
PARAMÈTRES COMMUNS
version-précédente
Indique la dernière version du paquet pour laquelle la mise à niveau doit provoquer
l'opération. Il est important de déterminer correctement version-précédente afin que
les opérations s'accomplissent 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 à niveau (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 raison ou une autre dans
plusieurs versions et que vous modifiez les scripts du responsable pour nettoyer
l'ancien fichier, version-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. Cela 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, version-précédente 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épertoire (fourni dans la version 2.0-1), mais ne réalise
réellement la substitution que dans les scripts du responsable dans la version 3.0-1,
version-précédente doit être 3.0-1~.
paquet
Le nom du paquet propriétaire du (des) nom(s) de chemin. Si le paquet est « Multi-
Arch: same » ce paramètre doit inclure le type d'architecture, sinon, il ne devrait
pas habituellement inclure le type d'architecture (parce qu'il pourrait interdire les
catégories croisées, ou le passage d'une architecture spécifique à l'architecture all
ou vice-versa). Si le paramètre est vide ou omis, les variables d'environnement
DPKG_MAINTSCRIPT_PACKAGE et DPKG_MAINTSCRIPT_ARCH (telles que définies par dpkg lors
de l'exécution des scripts du responsable) seront utilisées pour créer un nom de
paquet avec une qualification d'architecture.
-- Tous les paramètres des scripts du responsable doivent être passés au programme après
--.
TÂCHES LIÉES AUX FICHIERS DE CONFIGURATION
Lors de la mise à niveau d'un paquet, dpkg ne supprime pas un fichier de configuration
automatiquement (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é à l'aide des 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 à
l'aide de scripts du responsable.
Supprimer un fichier de configuration
Note: This can be replaced in most cases by the "remove-on-upgrade" flag in
DEBIAN/conffiles (since dpkg 1.20.6), see deb-conffiles(5).
Si un fichier de configuration est complètement supprimé, il doit être effacé du disque
sauf si l'administrateur local l'a modifié. Les éventuelles modifications locales doivent
être conservées. Si la mise à jour du paquet est interrompue, le fichier de configuration
rendu obsolète ne doit pas avoir disparu.
L'ensemble de ces pré-requis est mis en œuvre en utilisant les commandes shell suivantes
dans les scripts preinst, postinst et postrm :
dpkg-maintscript-helper rm_conffile \
fichier-de-configuration version-précédente paquet -- "$@"
fichier-de-configuration est le nom du fichier de configuration à supprimer.
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-configuration nouveau-fichier-configuration
version-précédente paquet -- "$@"
ancien-fichier-configuration et nouveau-fichier-configuration 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-configuration.dpkg-remove s'il ne l'a pas été.
Lors de la configuration, le script postinst supprime ancien-fichier-
configuration.dpkg-remove et renomme ancien-fichier-configuration et nouveau-fichier-
configuration si ancien-fichier-configuration existe toujours. Si la mise à jour ou
l'installation sont interrompues, le script postrm renomme ancien-fichier-
configuration.dpkg-remove en ancien-fichier-configuration si c'est indispensable.
SUBSTITUTIONS DE LIENS SYMBOLIQUES ET DE RÉPERTOIRES
Lors de la mise à niveau d'un paquet, dpkg ne substitue pas automatiquement 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.
Note: The symlinks and directories created during these switches need to be shipped in the
new packages, or dpkg will not be able to remove them on purge.
Substituer un lien symbolique à un répertoire
Si un lien symbolique est substitué à un répertoire réel, il est nécessaire de garantir
qu'avant le dépaquetage 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 à niveau 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écessaire de garantir
qu'avant le dépaquetage 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épertoire 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 chemin 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
provisoire. 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 à niveau ou l'installation sont interrompues, le script postrm renomme nom-de-
chemin.dpkg-backup en nom-de-chemin si c'est indispensable.
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
symlink_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épendance, il est possible de ne lancer le
programme que si on a la certitude 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.
ENVIRONNEMENT
DPKG_ROOT
Si cette variable est positionnée, ce répertoire sera utilisé comme répertoire racine
du système de fichiers.
DPKG_ADMINDIR
Si cette variable est positionnée, ce répertoire sera utilisé comme répertoire de
données pour dpkg.
DPKG_COLORS
Fixe le mode de couleur (depuis dpkg 1.19.1). Les valeurs admises actuellement sont
auto (par défaut), always et never.
VOIR AUSSI
dh_installdeb(1)
TRADUCTION
Ariel VARDI <ariel.vardi@freesbee.fr>, 2002. Philippe Batailler, 2006. Nicolas François,
2006. Veuillez signaler toute erreur à <debian-l10n-french@lists.debian.org>.