Provided by: dpkg_1.19.0.5ubuntu2.4_amd64 bug

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-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 à jour 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 à 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 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. 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é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, dernière-version doit être 3.0-1~.

       paquet The package name owning the pathname(s). 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  architecture  specific  to
              architecture   all   or   vice   versa).   If   the   parameter   is   empty   or   omitted,   the
              DPKG_MAINTSCRIPT_PACKAGE and DPKG_MAINTSCRIPT_ARCH environment variables  (as  set  by  dpkg  when
              running the maintainer scripts) will be used to generate an arch-qualified package name.

       --     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 à jour d'un paquet, dpkg ne supprime pas automatiquement 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 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 dernière-version 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 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 configuration,  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 indispensable.

SUBSTITUTIONS DE LIENS SYMBOLIQUES ET DE RÉPERTOIRES

       Lors  de  la  mise  à  jour  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é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écessaire 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é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 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 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  à  jour  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.

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

1.19.0.5                                           2022-05-25                         dpkg-maintscript-helper(1)