diff options
Diffstat (limited to 'man/fr/dpkg-maintscript-helper.pod')
-rw-r--r-- | man/fr/dpkg-maintscript-helper.pod | 350 |
1 files changed, 350 insertions, 0 deletions
diff --git a/man/fr/dpkg-maintscript-helper.pod b/man/fr/dpkg-maintscript-helper.pod new file mode 100644 index 0000000..f54c550 --- /dev/null +++ b/man/fr/dpkg-maintscript-helper.pod @@ -0,0 +1,350 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +dpkg-maintscript-helper - Contournement des limitations connues de dpkg dans +les scripts du responsable + +=head1 SYNOPSIS + +B<dpkg-maintscript-helper> I<commande> [I<paramètre>...] B<--> +I<paramètre-script-responsable>... + +=head1 COMMANDES ET PARAMÈTRES + +=over + +=item B<supports> I<commande> + +=item B<rm_conffile> I<fichier-de-configuration> [I<version-précédente> +[I<paquet>]] + +=item B<mv_conffile> I<ancien-fichier-de-configuration> +I<nouveau-fichier-de-configuration> [I<dernière-version> [I<paquet>]] + +=item B<symlink_to_dir> I<nom-de-chemin> I<ancienne-cible> [I<version-précédente> +[I<paquet>]] + +=item B<dir_to_symlink> I<nom-de-chemin> I<nouvelle-cible> [I<version-précédente> +[I<paquet>]] + +=back + +=head1 DESCRIPTION + +Ce programme est prévu pour être exécuté dans les scripts du responsable +afin de réaliser certaines tâches que B<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 (B<preinst>, B<postinst>, B<prerm>, B<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 B<DPKG_MAINTSCRIPT_NAME> et des paramètres des +scripts du responsable qui doivent être passés avec un double tiret. + +=head1 PARAMÈTRES COMMUNS + +=over + +=item I<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 +I<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 I<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, I<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 +B<2.0-1> d'un paquet, I<version-précédente> doit être B<2.0-1~>. Cela +provoquera la suppression du fichier même si la version précédente B<1.0-1> +a été reconstruite avec B<1.0-1local1> comme numéro de version. Ou bien, si +un paquet substitue un chemin d'un lien symbolique (fourni dans la version +B<1.0-1>) à un répertoire (fourni dans la version B<2.0-1>), mais ne réalise +réellement la substitution que dans les scripts du responsable dans la +version B<3.0-1>, I<version-précédente> doit être B<3.0-1~>. + +=item I<paquet> + +Le nom du paquet propriétaire du (des) nom(s) de chemin. Si le paquet est +S<« Multi-Arch:> S<same »> ce paramètre doit inclure le type d'architecture, +sinon, il ne devrait B<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 B<all> ou vice-versa). Si le +paramètre est vide ou omis, les variables d'environnement +B<DPKG_MAINTSCRIPT_PACKAGE> et B<DPKG_MAINTSCRIPT_ARCH> (telles que définies +par B<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. + +=item B<--> + +Tous les paramètres des scripts du responsable doivent être passés au +programme après B<-->. + +=back + +=head1 TÂCHES LIÉES AUX FICHIERS DE CONFIGURATION + +Lors de la mise à niveau d'un paquet, B<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 +B<dpkg-maintscript-helper> est donc de fournir des méthodes de suppression +ou renommage de fichiers de configuration à l'aide de scripts du +responsable. + +=head2 Supprimer un fichier de configuration + +Note: This can be replaced in most cases by the C<remove-on-upgrade> flag in +F<DEBIAN/conffiles> (since dpkg 1.20.6), see L<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 B<preinst>, B<postinst> et S<B<postrm> :> + +=over + +Z<> + dpkg-maintscript-helper rm_conffile \ + I<conffile> I<prior-version> I<package> -- "$@" + +=back + +I<fichier-de-configuration> est le nom du fichier de configuration à +supprimer. + +Détails de la mise en œuvre S<actuelle : dans> le script B<preinst>, il est +vérifié si le fichier de configuration a été modifié. Celui-ci est alors +renommé, soit en I<fichier-de-configuration>B<.dpkg-remove> s'il n'a pas été +modifié, soit en I<fichier-de-configuration>B<.dpkg-backup> s'il l'a +été. Dans le script B<postinst>, ce dernier fichier est ensuite renommé en +I<fichier-de-configuration>B<.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 B<postrm> remet en place le +fichier de configuration d'origine. À la purge du paquet, le script +B<postrm> supprimera également le fichier B<.dpkg-bak> qui avait été +conservé jusque là. + +=head2 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 +B<preinst>, mais cela risque de résulter en une demande, par B<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 B<preinst>, B<postinst> et S<B<postrm> :> + +=over + +Z<> + dpkg-maintscript-helper mv_conffile \ + I<old-conffile> I<new-conffile> I<prior-version> I<package> -- "$@" + +=back + +I<ancien-fichier-configuration> et I<nouveau-fichier-configuration> sont +l'ancien et le nouveau nom du fichier de configuration à renommer. + +Détails de la mise en œuvre S<actuelle : dans> le script B<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 +I<ancien-fichier-configuration>B<.dpkg-remove> s'il ne l'a pas été. Lors de +la configuration, le script B<postinst> supprime +I<ancien-fichier-configuration>B<.dpkg-remove> et renomme +I<ancien-fichier-configuration> et I<nouveau-fichier-configuration> si +I<ancien-fichier-configuration> existe toujours. Si la mise à jour ou +l'installation sont interrompues, le script B<postrm> renomme +I<ancien-fichier-configuration>B<.dpkg-remove> en +I<ancien-fichier-configuration> si c'est indispensable. + +=head1 SUBSTITUTIONS DE LIENS SYMBOLIQUES ET DE RÉPERTOIRES + +Lors de la mise à niveau d'un paquet, B<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. + +=head2 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 +B<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 B<preinst>, B<postinst> et S<B<postrm> :> + +=over + +Z<> + dpkg-maintscript-helper symlink_to_dir \ + I<pathname> I<old-target> I<prior-version> I<package> -- "$@" + +=back + +I<nom-de-chemin> est le nom absolu de l'ancien lien symbolique (le chemin +sera un répertoire à la fin de l'installation) et I<ancienne-cible> la cible +de l'ancien lien symbolique vers I<nom-de-chemin>. Cela peut être un chemin +absolu ou relatif vers le répertoire contenant I<nom-de-chemin>. + +Détails de la mise en œuvre S<actuelle :> dans le script B<preinst>, il est +vérifié si le lien symbolique existe et pointe vers I<ancienne-cible>. Si ce +n'est pas le cas, il est alors soit laissé en place, soit renommé en +I<nom-de-chemin>B<.dpkg-backup>. Lors de la configuration, le script +B<postinst> supprime I<nom-de-chemin>B<.dpkg-backup> si +I<nom-de-chemin>B<.dpkg-backup> est encore un lien symbolique. Si la mise à +niveau ou l'installation sont interrompues, le script B<postrm> renomme +I<nom-de-chemin>B<.dpkg-backup> en I<nom-de-chemin> si c'est indispensable. + +=head2 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 +B<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 B<preinst>, B<postinst> et S<B<postrm> :> + +=over + +Z<> + dpkg-maintscript-helper dir_to_symlink \ + I<pathname> I<new-target> I<prior-version> I<package> -- "$@" + +=back + +I<nom-de-chemin> est le nom absolu de l'ancien répertoire (le chemin sera un +lien symbolique à la fin de l'installation) et I<nouvelle-cible> la cible du +nouveau lien symbolique vers I<nom-de-chemin>. Cela peut être un chemin +absolu ou relatif vers le répertoire contenant I<nom-de-chemin>. + +Détails de la mise en œuvre S<actuelle :> dans le script B<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 I<nom-de-chemin>B<.dpkg-backup> et un +répertoire vide provisoire nommé I<nom-de-chemin> est créé, marqué par un +fichier pour que dpkg le suive. Lors de la configuration, le script +B<postinst> achève la substitution si I<nom-de-chemin>B<.dpkg-backup> est +encore un répertoire et si I<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 I<nouvelle-cible>, remplace le répertoire provisoire +I<nom-de-chemin>, maintenant vide, par un lien symbolique vers la +I<nouvelle-cible> et, enfin supprime I<nom-de-chemin>B<.dpkg-backup>. Si la +mise à niveau ou l'installation sont interrompues, le script B<postrm> +renomme I<nom-de-chemin>B<.dpkg-backup> en I<nom-de-chemin> si c'est +indispensable. + +=head1 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 B<dpkg-maintscript-helper> ce qui +vous facilitera la tâche. Voir par exemple B<dh_installdeb>(1). + +Comme B<dpkg-maintscript-helper> est utilisé dans le script B<preinst>, +l'utiliser sans conditions impose une pré-dépendance afin de garantir que la +version minimale nécessaire de B<dpkg> ait bien été préalablement +configurée. La version minimale dépend de la commande S<utilisée :> ainsi pour +B<rm_conffile> et B<mv_conffile>, cette version S<est 1.15.7.2,> pour +B<symlink_to_dir> et B<dir_to_symlink>, S<c'est 1.17.14 :> + +=over + + Pre-Depends: dpkg (>= 1.17.14) + +=back + +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 S<B<dpkg> :> + +=over + +Z<> + if dpkg-maintscript-helper supports I<command>; then + dpkg-maintscript-helper I<command> ... + fi + +=back + +La commande B<supports> retournera B<0> en cas de réussite, B<1> +autrement. Elle vérifiera si les variables d'environnement telles que +définies par B<dpkg> et requises par le script sont présentes, et +considérera que c'est un échec si l'environnement n'est pas suffisant. + +=head1 ENVIRONNEMENT + +=over + +=item B<DPKG_ROOT> + +If set, it will be used as the filesystem root directory. + +=item B<DPKG_ADMINDIR> + +If set, it will be used as the B<dpkg> data directory. + +=item B<DPKG_COLORS> + +Fixe le mode de couleur (depuis S<dpkg 1.19.1).> Les valeurs admises +actuellement sont B<auto> (par défaut), B<always> et B<never>. + +=back + +=head1 VOIR AUSSI + +B<dh_installdeb>(1) + + +=head1 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>. |