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