.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.40) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "DH 1" .TH DH 1 "2021-03-06" "13.3.4" "Debhelper" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NOM" .IX Header "NOM" dh \- Automate de commandes debhelper .SH "SYNOPSIS" .IX Header "SYNOPSIS" \&\fBdh\fR \fIsuite\fR [\fB\-\-with\fR \fIrajout\fR[\fB,\fR\fIrajout\fR ...]] [\fB\-\-list\fR] [\fIoptions_de_debhelper\fR] .SH "DESCRIPTION" .IX Header "DESCRIPTION" \&\fBdh\fR exécute une suite de commandes debhelper. Les \fIsuite\fRs acceptées correspondent aux blocs d'un fichier \fIdebian/rules\fR : \fBbuild-arch\fR, \&\fBbuild-indep\fR, \fBbuild\fR, \fBclean\fR, \fBinstall-indep\fR, \fBinstall-arch\fR, \&\fBinstall\fR, \fBbinary-arch\fR, \fBbinary-indep\fR et \fBbinary\fR. .SH "CIBLES DE RÉÉCRITURE ET D'ACCROCHE" .IX Header "CIBLES DE RÉÉCRITURE ET D'ACCROCHE" Un fichier \fIdebian/rules\fR utilisant \fBdh\fR peut réécrire la commande exécutée à n'importe quelle étape d'une séquence, en définissant une cible de réécriture. Il est possible d'injecter une commande avant ou après une étape sans affecter l'étape elle\-même. .SS "Injection de commandes avant ou après une étape" .IX Subsection "Injection de commandes avant ou après une étape" \&\fINote\fR : Cette fonctionnalité requiert debhelper 12.8 ou plus et le paquet doit utiliser le mode de compatibilité 10 ou plus. .PP Pour injecter des commandes avant \fIdh_command\fR, ajoutez une cible nommée \&\fBexecute_before_\fR\fIdh_command\fR aux fichiers de règles. De la même manière, si vous voulez injecter des commandes après \fIdh_command\fR, ajoutez la cible \&\fBexecute_after_\fR\fIdh_command\fR. Les deux cibles peuvent être utilisées pour la même \fIdh_command\fR, et même si la commande est réécrite (comme décrit plus loin dans \*(L"Réécriture d'une commande\*(R"). .PP Quand ces cibles sont définies, \fBdh\fR appellera les cibles respectivement avant ou après qu'il invoque \fIdh_command\fR (ou sa cible réécrite). .SS "Réécriture d'une commande" .IX Subsection "Réécriture d'une commande" Pour réécrire la commande \fIdh_commande\fR, ajoutez une cible appelée \&\fBoverride_\fR\fIdh_commande\fR au fichier \fIrules\fR. \fBdh\fR exécutera ce bloc au lieu d'exécuter \fIdh_commande\fR, comme il l'aurait fait sinon. La commande exécutée peut être la même commande avec des options supplémentaires ou une commande entièrement différente. Consultez les exemples ci-dessous. .SS "Cibles de réécriture et d'accroche dépendantes ou indépendantes de l'architecture" .IX Subsection "Cibles de réécriture et d'accroche dépendantes ou indépendantes de l'architecture" Les cibles de réécriture et d'accroche peuvent aussi être définies pour n'être exécutées que lors de la construction de paquets dépendants ou indépendants de l'architecture. Utilisez des cibles avec des noms comme \&\fBoverride_\fR\fIdh_commande\fR\fB\-arch\fR et \&\fBexecute_after\fR\fIdh_command\fR\fB\-indep\fR. .PP Cette fonctionnalité est disponible depuis debhelper 8.9.7 (pour les cibles de réécriture) et 12.8 pour les cibles d'accroche. .SS "Cibles complètement vides" .IX Subsection "Cibles complètement vides" Comme optimisation particulière, \fBdh\fR ignorera une cible si elle est complètement vide. C'est surtout utile pour les cibles réécrites où la commande sera simplement ignorée sans la charge de l'invocation d'une cible factice. .PP Notez que la cible doit être complètement vide pour que cela fonctionne : .PP .Vb 3 \& # Ignorer dh_toto – la bonne façon optimisée \& # Mettre ici une raison pour ignorer dh_toto \& override_dh_toto: \& \& \& \& # Ignorer dh_titi – la façon lente \& override_dh_titi: \& # Mettre ici une raison pour ignorer dh_titi \& # (ces commentaires font qu\*(Aqune cible factice est exécutée) .Ve .SS "La vérification des cibles est récupérée par \fBdh\fP" .IX Subsection "La vérification des cibles est récupérée par dh" Si vous voulez confirmer que \fBdh\fR a vu une cible de réécriture ou d'accroche, vous pouvez utiliser la commande suivante comme exemple : .PP .Vb 6 \& $ dh binary \-\-no\-act | grep dh_install | head \-n5 \& dh_installdirs \& dh_install \& debian/rules execute_after_dh_install \& dh_installdocs \& dh_installchangelogs .Ve .PP Le \fBdebian/rules execute_after_dh_install\fR dans la sortie signale que \fBdh\fR a enregistré une cible \fBexecute_after_dh_install\fR et devrait l'exécuter immédiatement après \fBdh_install\fR\|(1). .PP Notez que les \*(L"Cibles complètement vides\*(R" seront omises dans la liste ci-dessus. Cela rend un peu plus difficile le repérage lors de la recherche de l'omission d'un nom de commande. Mais autrement, le principe reste le même. .SS "Mises en garde sur les cibles d'accroche et les conditions de makefile" .IX Subsection "Mises en garde sur les cibles d'accroche et les conditions de makefile" Si vous choisissez d'envelopper une cible d'accroche dans des conditions de makefile, soyez conscient que \fBdh\fR calcule toutes les cibles d'accroche à l'avance et met en cache le résultat pour cette exécution. En outre, les conditions seront de nouveau invoquées quand \fBdh\fR appelle la cible d'accroche plus tard et supposera que la réponse n'a pas changé. .PP L'analyse et la mise en cache se produit \fBsouvent\fR avant que \fBdh\fR ne sache s'il va construire des paquets arch:any (\-a) ou/et arch:all (\-i) ce qui peut produire des résultats déconcertants – particulièrement si \&\fBdh_listpackages\fR\|(1) fait partie des conditions. .PP La majorité des problèmes peut être évitée en rendant la cible d'accroche inconditionnelle et ensuite en mettant le « corps » partiellement ou complètement conditionnel. Par exemple : .PP .Vb 10 \& # SIMPLE : ce qui arrive est bien défini. La cible d\*(Aqaccroche \& # est toujours prise en compte. La partie « maybe run this » est \& # conditionnelle mais dh_toto est définitivement oublié. \& # \& # S La condition est évaluée « deux fois » où elle influence \& # ce qui arrive. Une fois quand dh vérifie quelles cibles \& # d\*(Aqaccroche existent et une fois quand la cible d\*(Aqaccroche \& # override_dh_toto est exécutée. Si *une* fois, la sortie est \& # I, « maybe run this » est ignoré. \& override_dh_toto: \& ifneq (...) \& maybe run this \& endif \& \& # SIMPLE : cela est aussi bien défini. La cible d\*(Aqaccroche est \& # toujours exécutée et dh_titi est ignoré. La partie « may be \& # run this » est conditionnelle comme on pourrait s\*(Aqy attendre. \& # \& # Note : La condition est encore évaluée plusieurs fois (dans \& # différent processus chaque fois). Néanmoins, seule l\*(Aqévaluation \& # qui survient quand la cible d\*(Aqaccroche est exécutée influence ce \& # qui arrive. \& override_dh_titi: \& : # Commande factice pour toujours forcer l\*(Aqexécution de la cible \& ifneq (...) \& maybe run this \& endif \& \& \& \& # COMPLIQUÉ : Ce cas peut ne pas être trivial et présenter des \& # difficultés. À utiliser à vos risques et périls si dh_listpackages \& # est dans la condition. \& # \& # Ici, soit dh_truc est exécuté normalement OU « maybe run this » \& # est exécuté à sa place. \& # \& # Cela devient encore plus compliqué à résoudre si dh a besoin d\*(Aqitérer \& # dans debian/rules parce qu\*(Aqil y a une cible normale « explicite » \& # (par exemple une cible « build\-arch: » séparée de « %: »). \& ifneq (...) \& override_dh_truc: \& maybe run this \& endif .Ve .PP Ces recettes sont aussi pertinentes pour des cibles de dépendance conditionnelles qui sont souvent illustrées par une variante de l'exemple suivant : .PP .Vb 5 \& COND_TASKS = \& ifneq (...) \& COND_TASKS += maybe\-run\-this \& endif \& ... \& \& maybe\-run\-this: \& ... \& \& # SIMPLE : ce qui arrive est bien défini. Soit les \& # $(COND_TASKS) sont ignorées soit elles sont exécutées. \& # \& # Note : La condition est évaluée « deux fois » où elle influence \& # ce qui arrive. Une fois quand dh vérifie quelles cibles \& # d\*(Aqaccroche existent et une fois quand la cible d\*(Aqaccroche \& # override_dh_toto est exécutée. Si *une* fois, la sortie est \& # # I, $(COND_TASKS) sont ignorées. \& override_dh_toto: $(COND_TASKS) \& \& \& \& # SIMPLE : ceci est aussi bien défini. La cible d\*(Aqaccroche est \& # toujours exécutée et dh_titi est ignoré. La partie $(COND_TASKS) \& # est conditionnelle comme on pourrait s\*(Aqy attendre. \& # \& # Note : La condition est encore évaluée plusieurs fois (dans \& # différent processus chaque fois). Néanmoins, seule l\*(Aqévaluation \& # qui survient quand la cible d\*(Aqaccroche est exécutée influence ce \& # qui arrive. \& override_dh_titi: $(COND_TASKS) \& : # Commande factice pour toujours forcer l\*(Aqexécution de la cible \& \& # COMPLIQUÉ : ce cas peut ne pas être trivial et présenter des \& # difficultés. À utiliser à vos risques et périls si dh_listpackages \& # est dans la condition. \& # \& ifneq (...) \& override_dh_truc: $(COND_TASKS) \& endif .Ve .PP En cas de doute, choisissez le cas \fB\s-1SIMPLE\s0\fR qui correspond à vos besoins parmi les exemples ci-dessus. .SH "OPTIONS" .IX Header "OPTIONS" .IP "\fB\-\-with\fR \fIrajout\fR[\fB,\fR\fIrajout\fR ...]" 4 .IX Item "--with rajout[,rajout ...]" Ajoute les commandes debhelper indiquées par les rajouts au bon endroit dans la séquence exécutée. Cette option peut être présente plusieurs fois ou bien plusieurs rajouts peuvent être indiqués en les séparant par des virgules. Cela est utile lorsqu'un paquet tiers fournit des commandes debhelper. Consulter le fichier \fI\s-1PROGRAMMING\s0\fR pour obtenir des informations à propos de l'interface de ces rajouts. .Sp Une relation \fBBuild-Depends\fR sur le paquet \fBdh\-sequence\-\fR\fIrajout\fR implique \fB\-\-with\fR \fIrajout\fR. Cela évite un \fB\-\-with\fR explicite dans \&\fIdebian/rules\fR qui dupliquerait ce qui est écrit dans les dépendances de construction dans \fIdebian/control\fR. La relation peut (depuis 12.5) être rendue optionnelle au moyen de build-profiles par exemple. Cela permet de désactiver facilement un rajout qui est utile uniquement avec certains profils (par exemple pour faciliter l'amorçage). .Sp Depuis debhelper 12.5, les \fIrajout\fRs peuvent aussi être activés en mode « \fBindep\fR seulement » (au moyen de \fBBuild-Depends-Indep\fR) ou en mode « \fBarch\fR seulement » (au moyen de \fBBuild-Depends-Arch\fR). Ces rajouts sont seulement actifs dans la séquence particulière (par exemple \fBbinary-indep\fR) qui simplifie la gestion des dépendances pour les constructions croisées. .Sp Veuillez noter que les \fIrajout\fRs activés avec \fBBuild-Depends-Indep\fR ou \&\fBBuild-Depends-Arch\fR sont soumis à des contraintes supplémentaires pour s'assurer que le résultat est déterministe même quand le rajout n'est pas disponible (par exemple pendant le nettoyage). Cela implique que certains rajouts sont incompatibles avec ces restrictions et ne peuvent être utilisés qu'avec \fBBuild-Depends\fR (ou manuellement avec \&\fIdebian/rules\fR). Actuellement, ces rajouts peuvent seulement ajouter des commandes à des séquences. .IP "\fB\-\-without\fR \fIrajout\fR" 4 .IX Item "--without rajout" L'inverse de \fB\-\-with\fR, désactive le \fIrajout\fR donné. Cette option peut être présente plusieurs fois ou bien plusieurs rajouts peuvent être indiqués en les séparant par des virgules. .IP "\fB\-\-list\fR, \fB\-l\fR" 4 .IX Item "--list, -l" Liste tous les rajouts disponibles. .Sp Lorsqu'il est appelé uniquement avec cette option, \fBdh\fR peut être invoqué depuis n'importe quel répertoire (c'est\-à\-dire qu'il ne nécessite l'accès à aucun fichier d'un paquet source). .IP "\fB\-\-no\-act\fR" 4 .IX Item "--no-act" Affiche les commandes qui seraient utilisées pour une séquence donnée, sans les exécuter. .Sp Veuillez remarquer que \fBdh\fR élimine les commandes en cours lorsqu'il sait qu'elles ne font rien. Avec l'option \fB\-\-no\-act\fR, la liste complète des commandes dans une séquence est affichée. .PP Les autres options fournies à \fBdh\fR sont passées en paramètre à chaque commande exécutée. Cela est utile tant pour les options comme \fB\-v\fR, \fB\-X\fR ou \fB\-N\fR que pour des options plus spécialisées. .SH "EXEMPLES" .IX Header "EXEMPLES" Pour voir quelles commandes sont présentes dans une séquence, sans rien faire : .PP .Vb 1 \& dh binary\-arch \-\-no\-act .Ve .PP C'est un fichier \fIrules\fR très simple, pour les paquets où les séquences de commandes par défaut fonctionnent sans aucune option particulière. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ .Ve .PP Il est fréquent de vouloir passer une option à une commande debhelper. Le moyen le plus simple de le faire consiste à ajouter une cible pour surcharger la commande. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \& \& override_dh_strip: \& dh_strip \-Xtoto \& \& override_dh_auto_configure: \& dh_auto_configure \-\- \-\-with\-toto \-\-disable\-titi .Ve .PP Parfois les automatismes de \fBdh_auto_configure\fR\|(1) et de \&\fBdh_auto_build\fR\|(1) n'arrivent pas à deviner ce qu'il faut faire pour certains paquets tordus. Voici comment indiquer vos propres commandes plutôt que de laisser faire l'automatisme. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \& \& override_dh_auto_configure: \& ./mondoconfig \& \& override_dh_auto_build: \& make universe\-explode\-in\-delight .Ve .PP Un autre cas habituel consiste à vouloir faire quelque chose avant ou après l'exécution d'une certaine commande debhelper. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \& \& # L\*(Aqexemple suppose debhelper/12.8 et compat 10+ \& execute_after_dh_fixperms: \& chmod 4755 debian/truc/usr/bin/truc .Ve .PP Si vous avez une version de debhelper plus ancienne ou un niveau de compatibilité inférieur, l'exemple ci-dessus devrait être écrit de cette manière. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \& \& # Versions anciennes de debhelper ou avec un niveau \& # de compatibilité 9 ou moins. \& override_dh_fixperms: \& dh_fixperms \& chmod 4755 debian/truc/usr/bin/truc .Ve .PP Les outils Python ne sont pas exécutés par défaut par \fBdh\fR, à cause des modifications incessantes dans ce domaine. Voici comment utiliser \&\fBdh_python2\fR. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \-\-with python2 .Ve .PP Voici comment forcer l'utilisation du processus de construction \&\fBModule::Build\fR, propre à Perl, qui pourrait être indispensable si debhelper détectait, à tort, que le paquet utilise MakeMaker. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh \-\-buildsystem=perl_build $@ .Ve .PP Voici un exemple de remplacement où les commandes \fBdh_auto_\fR\fI*\fR cherchent la source du paquet car elle est située dans un sous\-répertoire. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \-\-sourcedirectory=src .Ve .PP Voici un exemple d'utilisation des commandes \fBdh_auto_\fR\fI*\fR pour réaliser la construction dans un sous\-répertoire qui sera ensuite supprimé lors du \&\fBclean\fR : .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \-\-builddirectory=build .Ve .PP Si le paquet peut être construit en parallèle, veuillez utiliser le niveau de compatibilité 10 ou passer l'option \fB\-\-parallel\fR à \fBdh\fR. Dans ce cas \&\fBdpkg-buildpackage \-j\fR fonctionnera. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \-\-parallel .Ve .PP Si votre paquet ne peut être construit de manière fiable en utilisant plusieurs processus légers, veuillez passer l'option \fB\-\-no\-parallel\fR à dh (ou la commande adéquate \fBdh_auto_\fR\fI*\fR) : .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \-\-no\-parallel .Ve .PP Voici un moyen d'empêcher \fBdh\fR d'exécuter plusieurs commandes, en définissant des blocs de substitution vides pour chaque commande que vous ne voulez pas lancer. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \& \& # Commandes que l\*(Aqon ne veut pas S \& override_dh_auto_test override_dh_compress override_dh_fixperms: .Ve .PP Un long processus de construction pour un paquet de documentation à part peut être séparé en utilisant des réécritures pour les paquets indépendants de l'architecture. Elles seront ignorées lors de l'exécution des suites build-arch et binary-arch. .PP .Vb 3 \& #!/usr/bin/make \-f \& %: \& dh $@ \& \& override_dh_auto_build\-indep: \& $(MAKE) \-C docs \& \& # Aucun test nécessaire pour la documentation \& override_dh_auto_test\-indep: \& \& override_dh_auto_install\-indep: \& $(MAKE) \-C docs install .Ve .PP En plus de l'exemple précédent, il peut être nécessaire de modifier les droits d'un fichier, mais seulement lors de la construction du paquet dépendant de l'architecture, puisqu'il n'est pas présent lors de la construction de la documentation toute seule. .PP .Vb 3 \& # L\*(Aqexemple suppose debhelper/12.8 et compat 10+ \& execute_after_dh_fixperms\-arch: \& chmod 4755 debian/truc/usr/bin/truc .Ve .SH "FONCTIONNEMENT INTERNE" .IX Header "FONCTIONNEMENT INTERNE" Si vous êtes curieux de connaître le fonctionnement interne de \fBdh\fR, voici ce qu'il y a sous le capot. .PP Dans les niveaux de compatibilité 10 (ou supérieurs), \fBdh\fR crée un fichier \&\fIdebian/debhelper\-build\-stamp\fR après la construction pour ne pas la refaire. Il est possible d'éviter la création de ce fichier en passant l'argument \fB\-\-without=build\-stamp\fR à \fBdh\fR. Cela rend le comportement des construction « no clean » plus cohérent avec l'usage courant au détriment de possiblement effectuer la construction et le test deux fois (la seconde en tant que « root » ou avec \fBfakeroot\fR\|(1)). .PP À l'intérieur d'une cible de réécriture, les commandes \fBdh_*\fR écrivent dans un journal \fIdebian/paquet.debhelper.log\fR pour savoir quelle commande a été exécutée pour quel paquet. Ces fichiers journaux seront supprimés une fois la cible de réécriture terminée. .PP Dans les niveaux de compatibilité 9 et précédents, chaque commande debhelper, qui s'accomplit correctement, est journalisée dans \&\fIdebian/package.debhelper.log\fR (que \fBdh_clean\fR supprimera). Ainsi \fBdh\fR peut déterminer quelles commandes ont déjà été exécutées et pour quels paquets. De cette manière il pourra passer outre l'exécution de ces commandes ultérieurement. .PP Chaque fois que \fBdh\fR est exécuté (en v9 ou précédente), il examine le journal et recherche la dernière commande exécutée dans la séquence indiquée. Puis il exécute la commande suivante dans cette séquence. .PP Une suite peut aussi exécuter des cibles dépendantes dans \&\fIdebian/rules\fR. Par exemple, la suite « binary » exécute la cible « install ». .PP \&\fBdh\fR utilise la variable d'environnement \fB\s-1DH_INTERNAL_OPTIONS\s0\fR pour transmettre des informations aux commandes debhelper exécutées au sein des blocs surchargés. Le contenu (et l'existence même) de cette variable d'environnement, comme son nom l'indique, est sujet à des modifications permanentes. .PP Les commandes des séquences \fBbuild-indep\fR, \fBinstall-indep\fR et \&\fBbinary-indep\fR sont appelées avec l'option \fB\-i\fR pour être certain qu'elles ne s'accompliront que sur des paquets indépendants de l'architecture. Symétriquement les commandes des séquences \fBbuild-arch\fR, \&\fBinstall-arch\fR et \fBbinary-arch\fR sont appelées avec l'option \fB\-a\fR pour être certain qu'elles ne s'accompliront que sur des paquets dépendants de l'architecture. .SH "VOIR AUSSI" .IX Header "VOIR AUSSI" \&\fBdebhelper\fR\|(7) .PP Ce programme fait partie de debhelper. .SH "AUTEUR" .IX Header "AUTEUR" Joey Hess .SH "TRADUCTION" .IX Header "TRADUCTION" Cette traduction est maintenue à l'aide de l'outil po4a par l'équipe francophone de traduction de Debian. .PP Veuillez signaler toute erreur de traduction en écrivant à ou par un rapport de bogue sur le paquet debhelper. .PP Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man \-L C
 ».