Provided by: dpkg_1.19.7ubuntu2_amd64 bug

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.

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

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