1 files changed, 213 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..33bb0b3
--- /dev/null
+++ b/man/fr/dpkg-maintscript-helper.pod
@@ -0,0 +1,213 @@
+
+        *****************************************************
+        *           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.
+
+Many of those tasks require coordinated actions from several maintainer scripts (B<preinst>, B<postinst>, B<prerm>, B<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 B<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.
+
+=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
+
+B<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)>.
+
+If a conffile is completely removed, it should be removed from disk, unless the user has modified it.  If there are local modifications, they should be preserved.  If the package upgrade aborts, the newly obsolete conffile should not disappear.
+
+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<fichier-de-configuration> I<version-précédente> I<paquet> -- "$@"
+
+=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<ancien-fichier-configuration> I<nouveau-fichier-configuration>
+    I<version-précédente> I<paquet> -- "$@"
+
+=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.
+
+B<Note>: The symlinks and directories created during these switches need to be shipped in the new packages, or B<dpkg> will not be able to remove them on purge.
+
+=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<nom-de-chemin> I<ancienne-cible> I<version-précédente> I<paquet> -- "$@"
+
+=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<nom-de-chemin> I<nouvelle-cible> I<version-précédente> I<paquet> -- "$@"
+
+=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
+
+When using a packaging helper, please check if it has native B<dpkg-maintscript-helper> integration, which might make your life easier. See for example L<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 est 1.15.7.2, pour B<symlink_to_dir> et B<dir_to_symlink>, c'est S<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<commande>; then
+    dpkg-maintscript-helper I<commande> ...
+ 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>
+
+Si cette variable est positionnée, ce répertoire sera utilisé comme répertoire racine du système de fichiers.
+
+=item B<DPKG_ADMINDIR>
+
+Si cette variable est positionnée, ce répertoire sera utilisé comme répertoire de données pour B<dpkg>.
+
+=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
+
+L<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>.