debhelper(7) | Debhelper | debhelper(7) |
debhelper - Ensemble d'outils regroupés sous le nom de debhelper
dh_* [-v] [-a] [-i] [--no-act] [-ppaquet] [-Npaquet] [-Ptmpdir]
Debhelper facilite la construction des paquets Debian. La philosophie qui sous-tend debhelper est de fournir une collection de petits outils simples et facilement compréhensibles qui seront exploités dans debian/rules pour automatiser les tâches courantes liées à la construction des paquets, d'où un travail allégé pour le responsable. Dans une certaine mesure, cela signifie également que ces outils peuvent être adaptés aux modifications éventuelles de la Charte Debian. Les paquets qui utiliseront debhelper ne nécessiteront qu'une simple reconstruction pour être conformes aux nouvelles règles.
Un fichier debian/rules typique, exploitant debhelper, appellera séquentiellement plusieurs des commandes de debhelper ou bien utilisera dh(1) pour automatiser ce processus. Des exemples de fichiers debian/rules qui exploitent debhelper se trouvent dans /usr/share/doc/debhelper/examples/
Pour créer un nouveau paquet Debian en utilisant debhelper, il suffit de copier un des fichiers d'exemple et de le modifier manuellement. Il est possible également d'essayer le paquet dh-make qui contient une commande dh_make automatisant partiellement le processus. Pour se familiariser avec ces concepts, le paquet Debian maint-guide contient un cours sur la construction d'un premier paquet avec debhelper.
Sauf lorsque l'outil explicite le contraire, tous les outils debhelper sont prévus pour être exécutés dans le répertoire racine d'un paquet source désarchivé. Cela leur permet de trouver les fichiers debian/control.
Voici la liste des commandes de debhelper disponibles. Consulter leurs pages de manuel respectives pour obtenir des informations complémentaires.
Quelques commandes de debhelper sont obsolètes et ne devraient plus être utilisées.
Si le nom d'un programme commence par dh_ et qu'il n'est pas dans les listes ci-dessus, cela signifie qu'il ne fait pas partie de la suite debhelper. Cependant, il devrait tout de même fonctionner comme les autres programmes décrits dans cette page.
Beaucoup de commandes de debhelper utilisent des fichiers du répertoire debian/ pour piloter leur fonctionnement. Outre les fichiers debian/changelog et debian/control, qui se trouvent dans tous les paquets, et pas seulement dans ceux qui emploient debhelper, d'autres fichiers peuvent servir à configurer le comportement des commandes spécifiques de debhelper. Ces fichiers sont, en principe, nommés debian/paquet.toto (où paquet est, bien sûr, à remplacer par le nom du paquet concerné).
Par exemple, dh_installdocs utilise un fichier appelé debian/package.docs pour énumérer les fichiers de documentation qu'il installera. Consulter les pages de manuel des différentes commandes pour connaître le détail des noms et des formats des fichiers employés. D'une façon générale, ces fichiers de configuration énumèrent les fichiers sur lesquels devra porter l'action, à raison d'un fichier par ligne. Quelques programmes de debhelper emploient des paires fichier/destination voire des formats légèrement plus compliqués.
Veuillez noter que pour le premier (ou unique) paquet binaire listé dans debian/control, debhelper utilisera debian/toto lorsqu'il n'y a aucun fichier debian/paquet.toto. Cependant, c'est une bonne idée de garder le préfixe paquet. car c'est plus explicite. Les principales exceptions sont les fichiers que debhelper installe par défaut dans chaque paquet binaire lorsqu'il ne trouve pas de préfixe (comme debian/copyright ou debian/changelog).
Dans quelques rares cas, il peut être utile d'exploiter différentes versions de ces fichiers pour des architectures ou des systèmes d'exploitation différents. S'il existe des fichiers appelés debian/paquet.toto.ARCH ou debian/paquet.toto.OS, dans lesquels ARCH et OS correspondent respectivement au résultat de « dpkg-architecture -qDEB_HOST_ARCH » ou de « dpkg-architecture -qDEB_HOST_ARCH_OS », alors ils seront utilisés de préférence aux autres fichiers plus généraux.
En général, ces fichiers de configuration sont employés pour indiquer des listes de divers types de fichiers : documentation, fichiers d'exemple à installer, fichiers à déplacer et ainsi de suite. Lorsque cela se justifie, dans des cas comme ceux-ci, il est possible d'employer, dans ces fichiers, les jokers (wildcard) standards de l'interpréteur de commandes (shell) (? et * et [..]). Des commentaires peuvent être ajoutés dans ces fichiers : les lignes commençant par # sont ignorées.
La syntaxe de ces fichiers est volontairement simple, pour les rendre faciles à lire, à comprendre et à modifier.
À partir du niveau de compatibilité 13, il est possible d'utiliser des substitutions simples dans les fichiers de configuration de debhelper pour les outils suivants :
Toutes les variables de substitution sont de la forme ${toto} et les accolades sont obligatoires. Les noms de variable sont sensibles à la casse et sont constitués de caractères alphanumériques (a-zA-Z0-9), tirets (-), tirets bas (_) et deux points (:). Le premier caractère doit être alphanumérique.
Si vous avez besoin d'un dollar littéral qui ne déclenche pas une substitution, il est possible d'utiliser soit la substitution ${Dollar} soit la séquence ${}.
Les développements suivants sont disponibles :
En cas de doute, la variante DEB_HOST_* est celle qui fonctionnera à la fois pour les constructions natives et croisées
Pour des raisons de performance, debhelper tentera de résoudre d'abord ces noms à partir de l'environnement avant de consulter dpkg-architecture(1). Celà est mentionné principalement dans un esprit de complétude, car cela n'a pas d'importance dans la plupart des cas.
# Déclenche une erreurr ${NO_SUCH_TOKEN} # Se développe à la valeur littérale « ${NO_SUCH_TOKEN} » ${Dollar}{NO_SUCH_TOKEN}
Cette variante est l'équivalent de la séquence ${} et les deux sont interchangeables.
Cela peut être utile s'il est nécessaire d'inclure un caractère d'espacement littéral (par exemple une espace) là où il serait autrement dépouillé ou utilisé comme un séparateur.
Notez que toutes les variables doivent se développer à une valeur définie. Par exemple, si debhelper voit ${env:TOTO}, alors, il affirme que la variable d'environnement TOTO est réglée (elle peut être réglée à une chaîne vide).
Contraintes des substitutions
Pour éviter des boucles infinies et un épuisement de ressources, debhelper s’arrêtera avec une erreur si le texte renferme de nombreuses variables de substitution (50) ou si elles se développent au-delà d'une certaine taille (4096 caractères ou trois fois la longueur de l'entrée originale – peu importe laquelle est la plus grande).
Si vous avez besoin de plus de flexibilité, de nombreux outils de debhelper (par exemple dh_install(1)) prennent en charge l'exécution d'un fichier de configuration comme un script.
Pour utiliser cette fonctionnalité, il suffit de marquer le fichier comme exécutable (<chmod +x debian/paquet.install >). L'outil essaiera de l'exécuter et utilisera la sortie du script. Le plus souvent, vous pouvez utiliser dh-exec(1) comme interpréteur du fichier de configuration pour conserver la majorité de la syntaxe originale tout en gagnant en flexibilité.
Lorsque vous utilisez des fichiers de configuration exécutables de debhelper, veuillez vous souvenir des choses suivantes :
Autrement, la sortie sera utilisée exactement telle quelle. En particulier, debhelper ne développera pas les jokers, ni ne supprimera les commentaires ou les espaces de la sortie.
Si vous avez besoin de construire le paquet sur un système de fichiers où l'on ne peut pas désactiver le bit d'exécution, vous pouvez utiliser dh-exec(1) et son script strip-output.
Tous les programmes de debhelper acceptent les options suivantes.
Cette option est supprimée dans le niveau de compatibilité 12.
Certains programmes de debhelper acceptent les options ci-dessous. Consulter la page de manuel de chaque programme pour une explication complète du rôle de ces options.
Les programmes debhelper dh_auto_* comportent plusieurs processus de construction et déterminent, de manière heuristique, lequel utiliser et comment. Il peut être utile de modifier ce comportement par défaut. Tous ces programmes dh_auto_* acceptent les options suivantes, typiquement passées à dh(1), qui les passe ensuite à tous les programmes dh_auto_*.
Indique none comme buildsystem pour désactiver la sélection automatique.
Attention : La variante --sourcedir correspond à une option du même nom dans dh_install et dh_missing, etc., pour des raisons historiques. Alors qu'elles ont le même nom, elles ont des objectifs très différents et, dans certains cas, cela peut provoquer des erreurs quand cette variante est passée à dh (quand ensuite il le passe à tous les outils).
Si cette option n'est pas indiquée, la construction se fera dans l'arborescence source à moins que le processus exige ou préfère le faire en dehors de cette structure. Dans ce cas, le répertoire par défaut sera utilisé même si --builddirectory n'est pas indiqué.
Même si le système préfère utiliser, pour la construction, un répertoire situé en dehors de l'arborescence source, il autorise quand même la construction dans l'arborescence source. Pour cela, il suffit d'utiliser un chemin d'accès au répertoire de construction identique au chemin d'accès au répertoire source.
Si aucune de ces options n'est précisée, debhelper active la parallélisation par défaut (--parallel) dans le niveau de compatibilité 10 (ou supérieur), et la désactive (--no-parallel) dans les autres niveaux.
Pour des raisons d'optimisation, dh essaiera de ne pas passer ces options aux processus fils si elles ne sont pas nécessaires et qu'elles sont les seules options. Cela arrive en particulier lorsque DEB_BUILD_OPTIONS n'a pas de paramètre parallel (ou si sa valeur est 1).
En particulier, régler le maximum à 1 équivaut à l'utilisation de --no-parallel.
When passing this option, the concrete dh_auto_* tool will ignore the cache from dh(1) and retrigger a rebuild of these variables. This is useful in the very rare case where the package need to do multiple builds but with different ...FLAGS options. A concrete example would be needing to change the -O parameter in CFLAGS in the second build:
export DEB_CFLAGS_MAINT_APPEND=-O3 %: dh $@ override_dh_auto_configure: dh_auto_configure -Bbuild-deb ... DEB_CFLAGS_MAINT_APPEND=-Os dh_auto_configure \ --reload-all-buildenv-variables -Bbuild-udeb ...
Sans --reload-all-buildenv-variables dans le second appel à dh_auto_configure(1), la modification dans DEB_CFLAGS_MAINT_APPEND pourrait être ignorée parce que dh_auto_configure(1) pourrait utiliser la valeur mise en cache de CFLAGS fixée par dh(1).
Cette option est seulement disponible avec debhelper (>= 12.7~) quand le paquet utilise le niveau de compatibilité 9 ou supérieur.
Parfois, des modifications majeures de debhelper doivent être faites et vont briser la compatibilité ascendante. Ces modifications sont nécessaires pour conserver à debhelper ses qualités de conception et d'écriture, car les besoins changent et le savoir-faire de l'auteur s'améliore. Pour éviter que de tels changements ne cassent les paquets existants, un concept de niveau de compatibilité debhelper a été introduit. On devra préciser à debhelper le niveau de compatibilité qu'il doit employer, ce qui modifiera son comportement de diverses manières.
Dans la version actuelle de debhelper, vous pouvez spécifier le niveau de compatibilité à utiliser dans debian/control en ajoutant une dépendance de construction (Build-Depends) sur le paquet debhelper-compat. Par exemple, pour exploiter la version 13, assurez-vous d'indiquer dans debian/control :
Build-Depends: debhelper-compat (= 13)
Cela sert aussi à avoir une dépendance de construction sur une version suffisante de debhelper. Ainsi il n'est pas nécessaire d'indiquer une dépendance de construction particulière sur debhelper, sauf si vous avez besoin d'une mise à jour spécifique (comme pour l'introduction d'une nouvelle fonctionnalité ou une correction de bogue à l'intérieur d'un niveau de compatibilité).
Veuillez noter que debhelper ne fournit pas debhelper-compat pour experimental ou pour les niveaux en version bêta. Les paquets qui souhaitent expérimenter avec cela devraient utiliser debian/compat ou DH_COMPAT.
Les versions précédentes de debhelper nécessitaient d'indiquer le niveau de compatibilité dans le fichier debian/compat, et la version actuelle continue à le comprendre pour des raisons de compatibilité. Cependant, un paquet ne devrait pas spécifier son niveau de compatibilité par plusieurs méthodes à la fois. Pour utiliser cette méthode, debian/compat doit contenir le niveau de compatibilité comme une valeur entière, et rien d'autre. Si vous indiquez le niveau de compatibilité ainsi, votre paquet aura besoin d'une dépendance de construction versionnée sur debhelper, égale (ou supérieure) au niveau de compatibilité utilisé. Ainsi, si vous indiquez le niveau 13 dans debian/compat, assurez-vous que le fichier debian/control contient :
Build-Depends: debhelper (>= 13~)
Sauf indication contraire, toute la documentation de debhelper suppose l'utilisation du niveau de compatibilité le plus récent, et, dans la plupart des cas ne précise pas si le comportement est différent avec les niveaux de compatibilité antérieurs. De ce fait, si le niveau de compatibilité le plus récent n'est pas celui utilisé, il est fortement conseillé de lire les indications ci-dessous qui exposent les différences dans les niveaux de compatibilité antérieurs.
Les niveaux de compatibilité sont les suivants :
Si vous mettez à jour depuis un niveau de compatibilité antérieur, veuillez consulter debhelper-obsolete-compat(7).
Ce mode est déconseillé.
Ce mode est déconseillé.
Ce mode est déconseillé.
Ce mode est déconseillé.
(Obsolète puisque l'outil dh_pysupport a été retiré de Debian Stretch. Depuis debhelper 10.3, dh n'active plus cette séquence quel que soit le niveau de compatibilité)
Ce mode est déconseillé.
Application rétroactive aux niveaux de compatibilité antérieurs : dh n'accepte plus aucun de ces paramètres depuis debhelper 12.4.
Les principales conséquences de cela sont :
Exemple de ce qui pourrait mal se passer :
override_dh_toto: dh_toto -pmon_paquet override_dh_titi: dh_titi dh_toto --remaining
Dans ce cas, l'appel à dh_foo --remaining inclura aussi mon_paquet, car dh_foo -pmon_paquet a été exécuté dans une cible de réécriture différente. Ce problème n'est pas limité à --remaining et concerne aussi -a, -i, etc.
Cette fonctionnalité de compatibilité avait un bogue depuis sa création dans debhelper/9.20130516, qui la faisait échouer en compat 9 et précédent. Comme il n'y a eu aucun rapport de problème causé par ce bogue en 5 ans, cela a été supprimé plutôt que corrigé.
Le niveau de compatibilité 11 est déconseillé pour les nouveaux paquets parce qu'il souffre d'une interaction de fonctionnalités entre dh_installinit et dh_installsystemd faisant que les services ne fonctionnent pas correctement dans certains cas. Vous devriez envisager l'utilisation à la place des modes de compatibilité 10 ou 12. Plus de détails sur ce problème sont disponibles dans le bogue Debian n° 887904 et dans le message <https://lists.debian.org/debian-release/2019/04/msg01442.html>.
Les changements par rapport à la version 10 sont :
Veuillez noter que dh_installsystemd a un comportement légèrement différent dans certains cas (par exemple lors de l'utilisation du paramètre --name).
La grande majorité des paquets ne seront pas affectés par ce changement.
Les exceptions connues incluent la construction avec le profil nodoc, où les outils ci-dessus permettront un échec silencieux de la correspondance lorsque le motif est utilisé pour spécifier la documentation.
Note de migration : un bogue dans debhelper 11 jusqu'à 11.1.5 faisait que dh_installinfo ignorait --sourcedir de manière incorrecte.
De plus, cette fonction deviendra peut-être obsolète car l'amont a l'intention de retirer la prise en charge de la variable d'environnement PERL_USE_UNSAFE_INC. Lorsque ce sera le cas, cette variable sera aussi supprimée rétroactivement des niveaux de compatibilité existants.
Si un paquet source contient un seul paquet binaire dans debian/control, ou si aucun des paquets n'est un paquet -doc, alors ce changement n'a pas d'effet pour ce paquet source, et vous pouvez aller au changement suivant.
Par défaut, ces outils essaient maintenant de déterminer un « paquet principal pour la documentation » (que l'on appellera doc-main-package) pour chaque paquet -doc. S'ils trouvent un tel doc-main-package, ils installeront la documentation sous /usr/share/doc/doc-main-package pour le paquet considéré. C'est-à-dire que le chemin peut changer, mais la documentation est toujours fournie par le paquet -doc.
L'option --doc-main-package peut être utilisée si la détection automatique est insuffisante, ou pour réinitialiser le chemin à sa valeur précédente s'il y a une raison de diverger des recommandations de la Charte Debian.
Quelques documents ne sont pas affectés par ce changement. En particulier le fichier copyright, les fichiers changelog, README.Debian, etc. Ces fichiers seront toujours installés sous /usr/share/doc/package.
Ce changement peut forcer les outils à traiter plus de fichiers qu'avant.
Si une dépendance non versionnée est requise, cela peut être obtenu en passant -VNone à la place. Veuillez tout de même consulter dh_makeshlibs(1) pour l'utilisation des dépendances non versionnées.
Si un paquet amont particulier n'utilise pas la bonne valeur par défaut, le paramètre peut souvent être passé manuellement avec dh_auto_configure(1). Par exemple :
override_dh_auto_configure: dh_auto_configure -- --libexecdir=/usr/libexec
Remarquez le -- avant le paramètre --libexecdir.
Si vous avez une réécriture pour dh_installinit (par exemple pour l'appeler avec --no-start), vous en aurez sûrement besoin d'une pour dh_installsystemd aussi.
Ce changement amène dh_installinit à injecter un champ misc:Pre-Depends sur init-system-helpers (>= 1.54~). Veuillez vous assurer que le paquet utilise ${misc:Pre-Depends} dans son champ Pre-Depends avant de mettre à niveau vers la compat 12.
Les changements par rapport à la version 12 sont :
Cette fonctionnalité a changé entre debhelper 13 et debhelper 13.2.
Si vous ne voulez pas non plus de l'avertissement, veuillez omettre l'appel à dh_missing. Si l'automate de commandes dh est utilisé, vous pouvez faire cela en insérant une cible de réécriture vide dans le fichier debian/rules du paquet correspondant. Comme dans l’exemple :
# Désactive dh_missing override_dh_missing:
Notez que dh_installtmpfiles répond à debian/paquet.tmpfiles là où dh_installsystemd utilisait un nom sans le « s » final.
Veuillez consulter "Substitutions dans les fichiers de configuration de debhelper" pour la syntaxe et les variables de substitution disponibles. Pour ceux qui écrivent des outils dh_*, le développement de substitution intervient comme élément des fonctions filearray et filedoublearray.
Tout paquet comptant sur ces cibles pour être toujours exécuté devrait plutôt déplacer la logique correspondante de ces cibles. Par exemple, le code d’empaquetage non lié aux tests provenant de override_dh_auto_test devrait avoir été déplacé dans execute_after_dh_auto_build ou execute_before_dh_auto_install.
dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...
Les changements par rapport à la version 13 sont :
Cela peut provoquer des problèmes avec l'exécution de binaires directement à partir des répertoires de construction parce qu'ils pourraient maintenant requérir une configuration manuelle de LD_LIBRARY_PATH. S'il est nécessaire de réécrire cette modification, il est recommandé d'essayer de passer d'abord l'option -DCMAKE_SKIP_RPATH=OFF pour voir si cela corrige le problème (laissant CMAKE_BUILD_RPATH_USE_ORIGIN à sa nouvelle valeur par défaut). Cela devrait supprimer la nécessité de LD_LIBRARY_PATH et éviter les problèmes de reproductibilité dans Linux où $ORIGIN est pris en charge par les créateurs de liens lors de l'exécution.
Si le paquet source produit plus d'un paquet binaire, les programmes de debhelper construiront tous les paquets binaires. Si le paquet source doit construire un paquet dépendant de l'architecture et un paquet indépendant de l'architecture, ce comportement ne conviendra pas. En effet, il convient de construire les paquets dépendants de l'architecture dans « binary-arch » de debian/rules, et les paquets indépendants de l'architecture dans « binary-indep ».
Pour résoudre ce problème, et pour un meilleur contrôle sur la construction des paquets par debhelper, tous les programmes de debhelper acceptent les options -a, -i, -p et -s. Ces options sont cumulatives. Si aucune n'est précisée, les programmes de debhelper construisent tous les paquets énumérés dans le fichier de contrôle, avec les exceptions ci-dessous.
Tout d'abord, chaque paquet dont le champ Architecture de debian/control ne contient pas l'architecture DEB_HOST_ARCH sera exclu ("Charte Debian," section 5.6.8).
De plus, quelques autres paquets peuvent être exclus suivant le contenu de la variable d'environnement DEB_BUILD_PROFILES et les champs Build-Profiles des paragraphes debian/control dans les paquets binaires, conformément au brouillon de la charte (voir <https://wiki.debian.org/BuildProfileSpec>).
Interaction entre les sélections de paquets et les Build-Profiles
Les profils de construction (« Build-Profiles ») ont un effet sur le choix des paquets inclus dans les mécanismes de sélection de paquets de debhelper. Généralement, les sélections partent du principe que tous les paquets sont activés. Cette section décrit comment les sélections fonctionnent lorsqu'un paquet est désactivé par un profil de construction (ou par son absence).
Veuillez noter que vous recevrez un avertissement si tous les paquets relatifs à cette sélection sont désactivés. Dans ce cas, il est généralement d'aucune utilité de construire.
Veuillez noter que cela n'a pas d'importance que le paquet soit activé ou désactivé par défaut.
Certaines commandes de debhelper produisent automatiquement des lignes de code de maintenance du paquet. Pour les inclure dans vos propres scripts de maintenance du paquet, il convient d'ajouter #DEBHELPER# à l'endroit où les lignes de code générées devront être insérées. #DEBHELPER# sera remplacé, par les lignes de code générées automatiquement, lors de l'exécution de dh_installdeb.
Si un script de maintenance n'existe pas et que debhelper doit y inclure quelque chose, alors debhelper créera le script de maintenance complètement.
Toutes les commandes de debhelper qui produisent automatiquement des lignes de code de cette façon peuvent inhiber cette production grâce à l'option -n (voir ci-dessus).
Nota : Les lignes de code insérées seront écrites dans le langage de l'interpréteur de commandes (shell). De ce fait, il est impossible de les placer directement dans un script Perl. Pour les insérer dans un script Perl, voici une solution (s'assurer que $1, $2, etc., sont bien définis par la commande set) :
my $temp="set -e\nset -- @ARGV\n" . << 'EOF'; #DEBHELPER# EOF if (system($temp)) { my $exit_code = ($? >> 8) & 0xff; my $signal = $? & 0x7f; if ($exit_code) { die("Le script debhelper a échoué avec le code d'erreur : ${exit_code}"); } else { die("Le script debhelper a été tué par le signal : ${signal}"); } }
Certaines commandes de debhelper peuvent nécessiter des dépendances entre le paquet construit et d'autres paquets. Par exemple, si dh_installdebconf(1) est employé, le paquet devra dépendre de debconf. Si dh_installxfonts(1) est employé, le paquet deviendra dépendant d'une version particulière de xutils. Maintenir ces dépendances induites peut être pénible puisqu'elles découlent de la façon dont debhelper travaille. C'est pourquoi debhelper offre une solution d'automatisation.
Toutes les commandes de ce type, outre qu'elles documentent, dans leur page de manuel, les dépendances qu'elle induisent, généreront automatiquement une variable de substitution nommée ${misc:depends}. Si cette variable est exploitée dans le dossier debian/control, il sera automatiquement enrichi des dépendances induites par debhelper.
Ce processus est entièrement indépendant de ${shlibs:Depends} standard, produite par dh_makeshlibs(1), et de ${perl:Depends} produite par dh_perl(1). Il est également possible de choisir de ne pas les utiliser si les conjectures de debhelper ne correspondent pas à la réalité.
Par défaut, tous les programmes de debhelper supposent que le répertoire temporaire utilisé pour construire l'arborescence des fichiers d'un paquet est debian/paquet.
Parfois, il peut être souhaitable d'utiliser un autre répertoire temporaire. C'est obtenu grâce à l'attribut -P. Par exemple, dh_installdocs -Pdebian/tmp utilisera debian/tmp comme répertoire temporaire. Nota : L'usage de -P implique que les programmes de debhelper ne construisent qu'un seul paquet à la fois. De ce fait, si le paquet source génère plusieurs paquets binaires, il faudra employer également le paramètre -p pour préciser l'unique paquet binaire à construire.
Debhelper prend en charge la construction des udebs. Pour créer un udeb avec debhelper, il faut ajouter « Package-Type: udeb » aux lignes de paquet dans debian/control. Debhelper essayera de construire des udebs, conformément aux règles de l'installateur Debian, en suffixant les fichiers de paquets générés avec .udeb, en n'installant aucune documentation dans un udeb, en omettant les scripts preinst, postrm, prerm et config, etc.
Cette section décrit certaines des variables d'environnement qui influencent le comportement de debhelper ou avec lesquelles debhelper est en interaction.
Il est important de noter que celles-ci doivent être des variables existantes pour affecter le comportement de debhelper (pas simplement des variables de Makefile). Pour les définir proprement dans le fichier debian/rules, assurez-vous de les exporter (« export »). Par exemple « export DH_VERBOSE ».
En utilisant dh(1), des options peuvent être passées à chaque commande debhelper, ce qui est généralement mieux que d'utiliser DH_OPTIONS.
Cela peut être utile pour construire un paquet à partir d'une arborescence CVS. Dans ce cas, le réglage de DH_ALWAYS_EXCLUDE=CVS empêchera les répertoires CVS d'interférer subrepticement dans le paquet en construction. Ou, si un paquet possède une source compressée, (maladroitement) présente dans un répertoire CVS, il peut être utile d'exporter DH_ALWAYS_EXCLUDE=CVS dans debian/rules, pour que cette variable soit prise en compte quel que soit l'endroit où le paquet est construit.
Des exclusions multiples peuvent être séparées avec des caractères deux points, comme dans DH_ALWAYS_EXCLUDE=CVS:.svn.
Cela est prévu pour être utilisé par les dérivées ou les configurations locales spécifiques qui ont besoin d'un rajout lors de plusieurs construction, sans avoir à modifier un grand nombre de fichier rules. Il est préférable d'éviter cette méthode et d'utiliser plutôt les drapeaux --with dans le fichier rules.
Notez que DPKG_COLOR affecte aussi un certain nombre d'outils liés à dpkg et debhelper l'utilise en supposant que vous voulez les même réglages de couleur pour dpkg et debhelper. Au cas où vous voudriez un autre jeu de couleurs pour debhelper, vous pouvez utiliser DH_COLORS à la place ou en plus de DPKG_COLORS.
Cette variable est définie conformément à <https://no-color.org/>. Dans ce projet, les variables d'environnement (comme DH_COLORS) sont considérées comme une demande explicite de couleur.
Le répertoire HOME sera créé comme un répertoire vide mais il sera réutilisé entre les appels à dh_auto_*. Tout son contenu restera jusqu'à ce qu'il soit explicitement supprimé ou jusqu'à l'exécution de dh_clean.
Veuillez noter que cette variable ne devrait pas être modifiée par les responsables de paquet dans debian/rules pour changer le comportement de debhelper. Ils devraient plutôt rechercher à désactiver la fonction correspondante directement (par exemple en surchargeant les outils spécifiques).
Cela est documenté ici parce qu'elle porte un nom identique à DEB_BUILD_OPTIONS, ce qui fait que certaines personnes pensent par erreur que debhelper réagit aussi à cette variable.
La suite d'outils de debhelper réagit aux paramètres suivants dans DEB_BUILD_OPTIONS.
Quand dherroron est présent et réglé à obsolete-compat-levels, alors les outils de debhelper présenteront dans les erreurs des alertes sur l'utilisation des niveaux de compatibilité anciens sur le point d'être obsolètes
C'est utile pour la vérification automatique de code se basant sur des niveaux de compatibilité dont la suppression est programmée.
Cette option est destinée aux tests et non aux constructions pour la production.
Cette valeur fera que les outils officiels de debhelper ignoreront les actions et les outils qui suppriment, détachent ou dédoublent les symboles de débogage dans les binaires ELF.
Cette valeur affecte dh_dwz(1) et dh_strip(1).
Les responsables de paquet cherchant à éviter l'exécution des tests de l'amont ne devraient pas recourir à cela. Ils peuvent plutôt ajouter une cible de réécriture vide pour ignorer dh_auto_test.
Cette valeur affecte dh_auto_test(1).
Cette valeur fera que plusieurs outils de debhelper ignoreront l'installation de documentation comme les pages de manuel ou la documentation fournie par l'amont. En plus, les outils ne sauront pas si la documentation déclarée est « missing » en partant du principe que la documentation n'a pas été construite.
Cette valeur affecte des outils comme dh_installdocs(1) qui sait qu'il travaille sur la documentation.
Cette valeur fait que debhelper ignore la création des paquets de symboles de débogage générés automatiquement.
Cette valeur affecte dh_strip(1).
Cette valeur affecte de nombreux outils de debhelper et en particulier dh_auto_* qui tentera d'exécuter le système de construction amont sous-jacent avec ce nombre de thread.
Cette valeur affecte la plupart des outils de dh_auto_*.
Les paramètres inconnus sont ignorés silencieusement.
Veuillez noter que les outils tiers dans le style de debhelper ou les systèmes de construction fournis par des tiers peuvent réagir ou non aux paramètres ci-dessus. Cela dépend généralement des détails d'implémentation des outils
Joey Hess <joeyh@debian.org>
Cette traduction est maintenue à l'aide de l'outil po4a <URL:http://po4a.alioth.debian.org/> par l'équipe francophone de traduction de Debian.
Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet debhelper.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C <section> <page_de_man> ».
2021-03-06 | 13.3.4 |