Ubuntu Manpage: debhelper - Ensemble d'outils regroupés sous le nom de debhelper

NOM

       debhelper - Ensemble d'outils regroupés sous le nom de debhelper

SYNOPSIS

       dh_* [-v] [-a] [-i] [--no-act] [-ppaquet] [-Npaquet] [-Ptmpdir]

DESCRIPTION

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.

COMMANDES DE DEBHELPER

       Voici la liste des commandes de debhelper disponibles. Consulter leurs pages de manuel respectives pour
       obtenir des informations complémentaires.

       dh_auto_build(1)
           Construire automatiquement un paquet

       dh_auto_clean(1)
           Faire le ménage automatiquement après une construction de paquet

       dh_auto_configure(1)
           Configurer automatiquement un paquet préalablement à sa construction

       dh_auto_install(1)
           Lancer automatiquement make install ou équivalent

       dh_auto_test(1)
           Exécuter automatiquement le jeu d'essai d'un paquet

       dh_bugfiles(1)
           Installer  les  fichiers  de  personnalisation  de rapports de bogue dans les répertoires des paquets
           construits

       dh_builddeb(1)
           Construire des paquets binaires Debian

       dh_clean(1)
           Nettoyer les répertoires de construction du paquet

       dh_compress(1)
           Compresser les fichiers  dans  le  répertoire  de  construction  du  paquet  et  modifier  les  liens
           symboliques en conséquence

       dh_dwz(1)
           Optimiser l'information de débogage DWARF dans les binaires ELF grâce à dwz

       dh_fixperms(1)
           Ajuster les droits sur les fichiers du répertoire de construction du paquet

       dh_gencontrol(1)
           Produire et installer le fichier de contrôle

       dh_icons(1)
           Mettre à jour les caches des icônes Freedesktop

       dh_install(1)
           Installer les fichiers dans le répertoire de construction du paquet

       dh_installcatalogs(1)
           Installer et inscrire les catalogues SGML

       dh_installchangelogs(1)
           Installer les journaux de suivi des modifications (changelog) dans les répertoires de construction du
           paquet

       dh_installcron(1)
           Installer les scripts cron dans etc/cron.*

       dh_installdeb(1)
           Installer des fichiers dans le répertoire DEBIAN

       dh_installdebconf(1)
           Installer les fichiers utilisés par debconf dans les répertoires de construction du paquet

       dh_installdirs(1)
           Créer des sous-répertoires dans le répertoire de construction du paquet

       dh_installdocs(1)
           Installer la documentation dans le répertoire de construction du paquet

       dh_installemacsen(1)
           Inscrire un paquet additionnel Emacs

       dh_installexamples(1)
           Installer les fichiers d'exemples dans le répertoire de construction du paquet

       dh_installifupdown(1)
           Installer les accroches (hooks) if-up et if-down

       dh_installinfo(1)
           Installer les fichiers info

       dh_installinit(1)
           Installer les fichiers de service « init » dans le répertoire de construction du paquet

       dh_installinitramfs(1)
           Installer les accroches (hooks) pour initramfs et configurer les scripts de maintenance

       dh_installlogcheck(1)
           Installer les fichiers de règles de vérification des journaux (logcheck rulefiles) dans etc/logcheck/

       dh_installlogrotate(1)
           Installer les fichiers de configuration de la rotation des journaux (logrotate)

       dh_installman(1)
           Installer les pages de manuel dans le répertoire de construction du paquet

       dh_installmenu(1)
           Installer les fichiers du menu Debian dans le répertoire de construction du paquet

       dh_installmime(1)
           Installer les fichiers « mime » dans le répertoire de construction du paquet

       dh_installmodules(1)
           Inscrire les modules du noyau

       dh_installpam(1)
           Installer les fichiers de support de PAM

       dh_installppp(1)
           Installer les fichiers ppp.ip-up et ppp.ip-down

       dh_installudev(1)
           Installer les fichiers de règles udev

       dh_installwm(1)
           Inscrire un gestionnaire de fenêtres (window manager)

       dh_installxfonts(1)
           Inscrire les polices de caractères graphiques (X fonts)

       dh_link(1)
           Créer les liens symboliques dans le répertoire de construction du paquet

       dh_lintian(1)
           Installer les fichiers « override » de lintian dans le répertoire de construction du paquet

       dh_listpackages(1)
           Énumérer les paquets binaires que debhelper va traiter

       dh_makeshlibs(1)
           Créer automatiquement le fichier shlibs et exécuter dpkg-gensymbols

       dh_md5sums(1)
           Créer le fichier DEBIAN/md5sums

       dh_movefiles(1)
           Déplacer des fichiers depuis debian/tmp dans des sous-paquets

       dh_perl(1)
           Déterminer les dépendances Perl et fait le ménage après MakeMaker

       dh_prep(1)
           Faire le ménage en vue de construire un paquet Debian

       dh_shlibdeps(1)
           Déterminer les dépendances envers les bibliothèques partagées

       dh_strip(1)
           Dépouiller les exécutables, les bibliothèques partagées et certaines bibliothèques statiques

       dh_systemd_enable(1)
           Activer ou désactiver les fichiers unit de systemd

       dh_systemd_start(1)
           Démarrer/arrêter/redémarrer des fichiers unit de systemd

       dh_testdir(1)
           Vérifier le répertoire avant de construire un paquet Debian

       dh_testroot(1)
           Vérifier que le paquet est construit avec les droits nécessaires du superutilisateur (root)

       dh_usrlocal(1)
           Migrer les répertoires usr/local dans les scripts de maintenance du paquet

   Commandes obsolètes
       Quelques commandes de debhelper sont obsolètes et ne devraient plus être utilisées.

       dh_installmanpages(1)
           Ancien programme d'installation des pages de manuel (obsolète)

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

FICHIERS DE CONFIGURATION DE DEBHELPER

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.

Substitutions dans les fichiers de configuration de debhelper
À 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 :

• dh_clean

• dh_install

• dh_installcatalogs

• dh_installdeb

• dh_installdirs

• dh_installdocs

• dh_installexamples

• dh_installinfo

• dh_installman

• dh_installwm

• dh_link

• dh_missing

• dh_ucf

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 :

DEB_HOST_*, DEB_BUILD_*, DEB_TARGET_*
Se développent à la valeur dpkg-architecture(1) adéquate (comme dpkg-architecture -qVARIABLE_HERE).

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.

Dollar
Se développe en un symbole $ littéral unique. Ce symbole ne sera jamais considéré comme faisant
partie d'une variable de substitution. C'est-à-dire :

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

Newline, Space, Tab
Se développent respectivement en un caractère ASCII saut de ligne, espace et tabulation.

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.

env:NOM
Se développe en la variable d'environnement NOM. La variable d'environnement doit être réglée (mais
elle peut être réglée à une chaîne vide).

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

Fichiers de configuration de l'exécutable debhelper.
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 :

• Le fichier de configuration exécutable doit se terminer avec succès (le code de retour doit
l'indiquer).

• À partir du niveau de compatibilité 13, la sortie sera sujette à des substitutions (voir
"Substitutions dans les fichiers de configuration de debhelper") lorsque l'outil les prend en charge.
N'oubliez d'être prudent si votre générateur fournit aussi des substitutions parce que cela peut
provoquer des confusions inutiles.

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.

OPTIONS PARTAGÉES DE DEBHELPER

Tous les programmes de debhelper acceptent les options suivantes.

-v, --verbose
Mode verbeux : affiche toutes les commandes qui modifient le répertoire de construction du paquet.

--no-act
Empêche la construction de s'effectuer réellement. Si cette option est utilisée avec -v, le résultat
sera l'affichage de ce que la commande aurait fait.

-a, --arch
Construit tous les paquets dépendants de l'architecture DEB_HOST_ARCH.

-i, --indep
Construit tous les paquets indépendants de l'architecture.

-ppaquet, --package=paquet
Construit le paquet nommé paquet. Cette option peut être répétée afin de faire agir debhelper sur
plusieurs paquets.

-s, --same-arch
Alias obsolète pour -a.

Cette option est supprimée dans le niveau de compatibilité 12.

-Npaquet, --no-package=paquet
Exclut le paquet indiqué du processus de construction, même si l'option -a, -i ou -p l'impliquait.

--remaining-packages
Exclut du processus de construction les paquets qui ont déjà été construits préalablement par cette
commande debhelper (c'est-à-dire, si la commande est présente dans le journal de debhelper du
paquet). Par exemple, si vous avez besoin d'invoquer la commande avec des options spéciales seulement
pour certains paquets binaires, utilisez cette option lors de la dernière invocation de la commande
pour construire le reste des paquets avec les options par défaut.

-Ptmpdir, --tmpdir=tmpdir
Utilise le répertoire tmpdir pour construire les paquets. Sinon, par défaut, le répertoire utilisé
est debian/paquet

--mainpackage=paquet
Cette option, peu utilisée, indique à debhelper le nom du « paquet principal » pour lequel les
fichiers debian/toto peuvent être utilisés à la place des fichiers habituels debian/paquet.toto. Par
défaut, debhelper considère que le « paquet principal » est le premier paquet énuméré dans le fichier
debian/control.

-O=option|ensemble
Cette option est utilisée par dh(1) pour passer une ou plusieurs options, indiquées par
l'utilisateur, à toutes les commandes exécutées. Si la commande prend en charge l'option ou
l'ensemble d'options, elle prendra effet. Si la commande n'accepte pas l'option (ou une partie de
l'ensemble d'options), elle sera ignorée.

OPTIONS COURANTES DE DEBHELPER

       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.

       -n  Ne pas modifier les scripts de maintenance du paquet (postinst, postrm, etc.)

       -Xélément, --exclude=élément
           Permet  d'exclure  un  élément  du  traitement.  Cette  option peut être employée plusieurs fois afin
           d'exclure plusieurs éléments. L'élément est en général une partie du nom  de  fichier,  et  tous  les
           fichiers contenant le texte indiqué seront exclus.

       -A, --all
           Précise  que les fichiers (ou autres éléments) indiqués dans la ligne de commande concernent tous les
           paquets construits et pas seulement le premier.

OPTIONS DU PROCESSUS DE CONSTRUCTION

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

-Sprocessus de construction, --buildsystem=processus_de_construction
Oblige à utiliser le processus de construction indiqué au lieu de tenter de déterminer
automatiquement celui qui pourrait être utilisable pour le paquet.

Indique none comme buildsystem pour désactiver la sélection automatique.

-Drépertoire, --sourcedir=répertoire, --sourcedirectory=répertoire
Considère que les sources du paquet sont situées dans le répertoire indiqué plutôt qu'au plus haut
niveau de l'arborescence du paquet source.

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

-B[répertoire], --builddir=[répertoire], --builddirectory=[répertoire]
Permet de construire le paquet en dehors de la structure source en utilisant le répertoire indiqué
comme répertoire de construction. Si le paramètre répertoire n'est pas indiqué, un répertoire de
construction par défaut sera choisi.

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.

--parallel, --no-parallel
Détermine si la construction parallèle doit être utilisée, si le système sous-jacent le permet. Le
nombre de tâches parallèles est contrôlé, lors de la construction, par la variable d'environnement
DEB_BUILD_OPTIONS ("Charte Debian," section 4.9.1). Ce nombre peut également être soumis aux limites
spécifiques du système de construction.

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

--max-parallel=maximum
Cette option implique --parallel et permet de limiter le nombre de tâches qui pourront être lancées
lors d'une compilation parallèle. Si la construction du paquet est connue pour ne fonctionner qu'avec
un certain niveau de parallélisme, il est possible de le régler à la valeur maximale censée
fonctionner, ou que vous souhaitez mettre en œuvre.

En particulier, régler le maximum à 1 équivaut à l'utilisation de --no-parallel.

--reload-all-buildenv-variables
Par défaut, dh(1) calculera plusieurs environnements (par exemple en utilisant dpkg-buildflags(1)) et
les met en cache pour éviter que tous les outils dh_auto_* les recalculent.

Lorsque cette option est passée, l'outil réel dh_auto_* ignorera le cache de dh(1) et déclenchera une
reconstruction de ces variables. Cela est utile dans le cas très rare où le paquet requiert de
multiples constructions mais avec des options ...FLAGS différentes. Un exemple concret pourrait être
la nécessité de modifier le paramètre -0 dans CFLAGS dans la seconde construction.

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.

--list, -l
Liste tous les processus de construction pris en charge par le système. Cette liste inclut à la fois
les processus par défaut et les processus tiers (marqués comme tels). Cette option montre également
le processus de construction automatiquement sélectionné ou celui indiqué manuellement avec l'option
--buildsystem.

NIVEAUX DE COMPATIBILITÉ

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.

Niveaux de compatibilité pris en charge
Les niveaux de compatibilité sont les suivants :

v7 Ce mode est déconseillé.

C'est le niveau de compatibilité le plus bas pris en charge.

Si vous mettez à jour depuis un niveau de compatibilité antérieur, veuillez consulter
debhelper-obsolete-compat(7).

v8 Les changements par rapport à la version 7 sont :

- Les commandes échoueront plutôt que de produire une alerte lorsqu'elles recevront des options
inconnues.

- dh_makeshlibs va exécuter le programme dpkg-gensymbols sur toutes les bibliothèques partagées
qu'il génère pour les fichiers shlibs. -X peut alors être utilisé pour exclure certaines
bibliothèques. En outre, les bibliothèques rangées à des emplacements inhabituels que pkg-
gensymbols n'aurait pas traitées avant qu'elles ne lui soient transmises, induisent un
changement de comportement qui peut causer l'échec de la construction de certains paquets.

- dh exige que la séquence à exécuter soit indiquée en tant que premier paramètre. Tous les
commutateurs doivent venir après. C'est-à-dire qu'il faut écrire « dh $@ --toto », et non
« dh --toto $@ »

- dh_auto_* utilise préférentiellement Module::Build de Perl au lieu de Makefile.PL.

Ce mode est déconseillé.

v9 Les changements par rapport à la version 8 sont :

- Prise en charge multiarchitecture. En particulier, dh_auto_configure passe les répertoires
multiarchitectures à autoconf dans --libdir et --libexecdir.

- dh connaît les dépendances classiques entre les cibles de debian/rules. Donc « dh binary »
exécutera toutes les cibles build, build-arch, build-indep, install, etc., présentes dans le
fichier rules. Il n'est pas nécessaire de définir une cible binary avec des dépendances
explicites sur les autres cibles.

- dh_strip compresse les fichiers de symboles de mise au point pour réduire la taille
d'installation des paquets -dbg.

- dh_auto_configure n'inclut pas le nom du paquet source dans --libexecdir en utilisant
autoconf.

- dh n'active pas --with=python-support par défaut.

(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é)

- Tous les programmes debhelper dh_auto_* et dh configurent les variables d'environnement
renvoyées par dpkg-buildflags, sauf si elles sont déjà configurées.

- dh_auto_configure passe les CFLAGS, CPPFLAGS et LDFLAGS de dpkg-buildflags à Makefile.PL et
Build.PL de Perl.

- dh_strip place les symboles de mise au point séparés à un endroit en fonction de leur
identifiant de construction (build-id).

- Les fichiers de configuration exécutables de debhelper sont exécutés et leur sortie est
utilisée comme configuration.

Ce mode est déconseillé.

v10 Les changements par rapport à la version 9 sont :

- dh_installinit n'installe plus de fichier nommé debian/<paquet> comme script
d'initialisation.

- dh_installdocs renverra une erreur s'il détecte des liens créés avec --link-doc entre des
paquets de l'architecture « all » et non-« all » car cela casse les binNMUs (envois de
binaires par quelqu'un d'autre que le responsable).

- dh_installdeb n'installe plus de fichier debian/<paquet>.shlibs fourni par le responsable du
paquet. Cela est maintenant effectué par dh_makeshlibs.

- dh_installwm refuse de créer un paquet cassé si aucune page de manuel ne peut être trouvée
(requis pour l'inscription de l'alternative x-window-manager).

- Debhelper active par défaut la parallélisation pour tous les systèmes de construction qui le
gèrent. Cela peut être désactivé en utilisant l'option --no-parallel ou en passant la valeur
1 à l'option --max-parallel.

- La commande dh n'acceptera aucun des paramètres obsolètes de « manual sequence control »
(--before, --after, etc.). Veuillez utiliser les cibles de réécritures à la place.

Application rétroactive aux niveaux de compatibilité antérieurs : dh n'accepte plus aucun de
ces paramètres depuis debhelper 12.4.

- La commande dh n'utilisera plus les fichiers journaux pour enregistrer quelles commandes ont
été exécutées. La commande dh se souvient toujours si la séquence « build » a été effectuée
et l'omet si c'est le cas.

Les principales conséquences de cela sont :

- Il est maintenant plus facile de déboguer les séquences install et binary parce qu'elles
peuvent maintenant être facilement re-exécutées (sans avoir à refaire un cycle complet de
« clean & rebuild »)

- La principale précaution est que dh_* enregistre uniquement ce qui s'est passé dans une
unique cible de réécriture. Lorsque tous les appels à une commande dh_cmd donnée arrivent
dans la même cible de réécriture, tout fonctionnera comme avant.

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.

- À présent, la commande dh_installdeb échappe les caractères du shell dans les lignes du
fichier de config maintscript. C'était l'intention originale mais cela n'a jamais fonctionné
correctement et les paquets ont commencé à compter sur l'échappement incomplet (p. ex. en
encadrant les noms de fichiers de guillemets).

- La commande dh_installinit utilise maintenant --restart-after-upgrade par défaut. Les paquets
nécessitant le comportement précédent devraient utiliser l'option --no-restart-after-upgrade.

- La séquence autoreconf est maintenant activée par défaut. Veuillez passer l'option --without
autoreconf à dh si cela n'est pas voulu pour certains paquets.

- La séquence systemd est maintenant activée par défaut. Veuillez passer l'option --without
systemd à dh si cela n'est pas voulu pour certains paquets.

- Supprimé rétroactivement : dh ne crée plus le répertoire de construction du paquet lors de
l'omission des commandes de debhelper en cours. Cela n'affectera pas les paquets qui se
construisent uniquement avec debhelper, mais pourrait faire apparaître des bogues dans les
commandes qui ne sont pas incluses avec debhelper.

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

v11 Ce mode est déconseillé.

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 :

- dh_installinit n'installe plus de fichiers service ou tmpfile, ni ne crée de scripts de
maintenance pour ces fichiers. Veuillez utiliser le nouvel assistant dh_installsystemd à la
place.

- Les outils dh_systemd_enable et dh_systemd_start ont été remplacés par un nouvel assistant
dh_installsystemd. Pour la même raison, la séquence systemd de dh a aussi été retirée. Si
vous avez besoin de désactiver dh_installsystemd, veuillez utiliser une cible de réécriture
vide.

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

- dh_installdirs ne crée plus les répertoires debian/paquet sans qu'on le lui demande
explicitement (ou il doit créer un sous-répertoire à l'intérieur).

La grande majorité des paquets ne seront pas affectés par ce changement.

- Le système de construction makefile passe maintenant les options INSTALL="install
--strip-program=true" à make(1). Les systèmes dérivés (comme configure ou cmake) ne sont pas
affectés par ce changement.

- Le système de construction autoconf passe maintenant l'option --runstatedir=/run à
./configure.

- Le système de construction cmake passe maintenant l'option -DCMAKE_INSTALL_RUNSTATEDIR=/run à
cmake(1).

- dh_installman préfère maintenant détecter le langage à partir du chemin plutôt que de
l'extension.

- dh_auto_install crée maintenant uniquement le répertoire de destination nécessaire.
Auparavant, le répertoire de construction de chaque paquet était créé. Cela n'affectera pas
les paquets qui se construisent uniquement avec debhelper, mais pourrait faire apparaître des
bogues dans les commandes qui ne sont pas incluses avec debhelper.

- Les outils dh_installdocs, dh_installexamples, dh_installinfo et dh_installman renvoient
maintenant une erreur si leur configuration contient un motif qui ne correspond à rien ou qui
référence un chemin qui n'existe pas.

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.

- Les outils dh_installdocs, dh_installexamples, dh_installinfo et dh_installman acceptent
maintenant le paramètre --sourcedir avec la même signification que dans dh_install. De plus,
ils se rabattent sur debian/tmp comme dh_install.

Note de migration : un bogue dans debhelper 11 jusqu'à 11.1.5 faisait que dh_installinfo
ignorait --sourcedir de manière incorrecte.

- Les systèmes de construction perl-makemaker et perl-build ne passent plus l'option -I. à
Perl. Les paquets qui ont encore besoin de ce comportement peuvent l'émuler en utilisant la
variable d'environnement PERL5LIB. Par exemple en ajoutant export PERL5LIB=. dans leur
fichier debian/rules (ou équivalent).

- La variable d'environnement PERL_USE_UNSAFE_INC n'est plus définie par dh, ni aucun des
outils dh_auto_*. Cela avait été ajouté comme contournement temporaire, pour éviter les
échecs de construction d’un grand nombre de paquets en même temps.

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.

- L'assistant dh_makeshlibs termine maintenant sur une erreur si objdump renvoie une valeur de
sortie différente de zéro lors de l'analyse d'un fichier.

- Les outils dh_installdocs et dh_installexamples pourraient maintenant installer la plupart de
la documentation dans un répertoire différent, pour satisfaire les recommandations de la
Charte Debian §12.3 (depuis la version 3.9.7).

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.

- Les outils dh_strip et dh_shlibdeps n'utilisent plus les motifs de noms de fichiers pour
déterminer les fichiers à traiter. À la place, ils ouvrent le fichier et cherchent un en-tête
ELF pour déterminer si ce fichier est un objet partagé ou un exécutable ELF.

Ce changement peut forcer les outils à traiter plus de fichiers qu'avant.

v12 Les changements par rapport à la version 11 sont :

- dh_makeshlibs génère maintenant des fichiers shlibs avec des dépendances versionnées par
défaut. Cela veut dire que -VUpstream-Version (ou -V) est maintenant le comportement par
défaut.

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.

- L'option -s (--same-arch) est supprimée. Veuillez utiliser -a (--arch) à la place.

- Appeler dh_clean -k provoque maintenant une erreur à la place de l'avertissement
d'obsolescence.

- L'option --no-restart-on-upgrade de dh_installinit a été supprimée. Veuillez utiliser le
nouveau nom --no-stop-on-upgrade.

- Il y avait un bogue dans les fonctions doit (et équivalent) de Debian::Debhelper::Dh_Lib qui
créait un shell dans une circonstance particulière. Ce bogue est maintenant supprimé et
provoquera une erreur de type « commande non trouvée » dans les outils qui l'utilisaient.

- Les options --list-missing et --fail-missing de dh_install ont été supprimées. Veuillez
utiliser dh_missing et ses options correspondantes, qui peuvent aussi voir les fichiers
installés par les autres outils.

- L'outil dh_installinit n'installe plus de configuration pour upstart. À la place, il
abandonnera la construction s'il trouve un ancien fichier de configuration upstart. Cela pour
rappeler au mainteneur de s'assurer de correctement supprimer les anciens fichiers de
configuration livrés dans les anciennes versions du paquet.

- L'outil dh_installdeb valide basiquement quelques commandes dpkg-maintscript-helper(1) et
renvoie une erreur si la commande semble incorrecte.

- Le comportement par défaut de dh_missing est maintenant --list-missing.

- dh_makeshlibs passera maintenant les bibliothèques à dpkg-gensymbols(1) si le binaire ELF a
un SONAME (contenant « .so »).

- dh_compress ne compresse plus les exemples (c'est-à-dire tout ce qui est installé dans
</usr/share/doc/paquet/examples>).

- La séquence standard de dh comprend maintenant dh_dwz et dh_installinitramfs par défaut. Cela
rend les séquences dwz et installinitramfs obsolètes et elles échoueront avec une erreur. Si
vous souhaitez sauter ces commandes, veuillez insérer des cibles de réécriture vides pour
elles dans debian/rules (par exemple override_dh_dwz:).

- Les systèmes de construction meson et autoconf ne positionnent plus explicitement la variable
--libexecdir, et s'appuient donc sur le système de construction par défaut – qui devrait être
/usr/libexec (selon la FHS 3.0, adoptée dans la Charte Debian 4.1.5).

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.

- Retroactively removed in debhelper/13.5:

The dh_installdeb tool would no longer installs the maintainer provided conffiles file as it
was deemed unnecessary. However, the remove-on-upgrade from dpkg/1.20 made the file relevant
again and dh_installdeb now installs it again in compat levels 12+.

- dh_installsystemd ne s'appuie plus sur dh_installinit pour s'occuper des services systemd qui
ont une alternative pour sysvinit. Les deux outils doivent maintenant être utilisés dans ce
cas pour s'assurer que le service est démarré correctement, à la fois avec systemd et
sysvinit.

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.

- L'outil tiers dh_golang (du paquet dh-golang) utilise maintenant la variable
DH_GOLANG_EXCLUDE pour l'installation des sources dans les paquets -dev, et plus uniquement
lors de la construction. Veuillez positionner DH_GOLANG_EXCLUDES_ALL à faux pour obtenir le
comportement précédent. Consultez Debian::Debhelper::Buildsystem::golang(3pm) pour plus de
détails et des exemples.

- dh_installsystemduser est maintenant inclus par défaut dans la séquence dh standard.

- Le système de construction python-distutils est supprimé. Veuillez utiliser le système tiers
pybuild à la place.

v13 C'est la version dont l'usage est recommandé.

Les changements par rapport à la version 12 sont :

- Le système de construction meson+ninja utilise maintenant meson test à la place de ninja test
pour la suite de tests. Chaque réécriture de dh_auto_test qui passe des paramètres
supplémentaires aux tests amont devrait être vérifiée, car meson test n'est pas compatible
avec ninja test.

- Tous les outils dans le style de debhelper basés sur la bibliothèque debhelper officielle (y
compris dh et les outils officiels dh_*) n'acceptent plus les paramètres de commande abrégés.
En même temps, dh optimise maintenant les appels aux outils redondants dh_* même quand ils
passent de longues options de ligne de commande.

- Les outils de debhelper liés à ELF (dh_dwz, dh_strip, dh_makeshlibs, dh_shlibdeps) sont
désormais seulement exécutés pour les paquets dépendant de l'architecture par défaut
(c'est-à-dire qu'ils sont exclus des cibles *-indep et sont passés avec l'option -a par
défaut). Si vous avez besoin d'eux pour des cibles *-indep, vous pouvez ajouter un Build-
Depends explicite à dh-sequence-elf-tools.

- Le système de construction tiers gradle (issu du paquet gradle-debian-helper) exécute
maintenant la suite de tests fournie par l'amont automatiquement. Pour supprimer ce type de
comportement, surchargez dh_auto_test.

- L'outil dh_installman s'interrompt maintenant s'il voit des définitions contradictoires d'une
page de manuel. Cela se produit habituellement si le système de construction amont installe
une version compressée et que le paquet liste une version non compressée de la page de manuel
dans debian/paquet.manpages. La correction la plus simple est de supprimer la page de manuel
de debian/paquet.manpages (en considérant que les deux versions sont identiques).

- Les outils dh_auto_* réinitialisent désormais les variables d'environnement HOME et la
variable commune XDG_*. Veuillez consulter la description des variables d'environnement dans
"ENVIRONMENT" pour voir comment elles sont gérées.

Cette fonctionnalité a changé entre debhelper 13 et debhelper 13.2.

- La commande dh produira maintenant une erreur si une cible de réécriture ou d'accroche pour
une commande obsolète est présente dans debian/rules (par exemple,
override_dh_systemd_enable:).

- La commande dh_missing aura l'option --fail-missing par défaut. Il est possible de revenir à
un avertissement non fatal en passant explicitement l'option --list-missing comme dans le
niveau de compatibilité 12.

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:

- L'automate de commandes dh exécute maintenant dh_installtmpfiles dans la séquence par défaut.
dh_installtmpfiles se charge de la gestion des fichiers de configuration de tmpfiles.d. La
fonctionnalité apparentée dans dh_installsystemd est désormais désactivée.

Notez que dh_installtmpfiles répond à debian/paquet.tmpfiles là où dh_installsystemd
utilisait un nom sans le « s » final.

- Beaucoup d'outils dh_* prennent en charge un développement de variables limité au moyen de la
syntaxe ${toto}. Dans de nombreux cas, cela peut être utilisé pour référencer des chemins qui
contiennent soit des espaces, soit des valeurs dpkg-architecture(1). Bien que cela puisse
réduire le besoin de dh-exec(1) dans certains cas, ce n'est pas une alternative à dh-exec(1)
en général. Si un filtrage, un renommage, etc. est nécessaire, le paquet aura encore besoin
de dh-exec(1).

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.

- L'automate de commandes dh omettra toutes les cibles d'accroche et de substitution pour
dh_auto_test, dh_dwz et dh_strip quand DEB_BUILD_OPTIONS liste les options nocheck ou nostrip
correspondantes.

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.

- Le système de construction cmake passe désormais l'option
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON à cmake(1) pour accélérer le processus d'installation
automatique. Si pour une raison quelconque vous avez besoin de revenir au comportement
antérieur, réécrivez le paramètre :

dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...

v14 Ce niveau de compatibilité est encore en développement ; à utiliser avec précaution.

Les changements par rapport à la version 13 sont :

- Le système de construction cmake passe maintenant les options -DCMAKE_SKIP_RPATH=ON et
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON à cmake(1) pour éviter des problèmes de reproductibilité.

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.

- The tool dh_installsysusers is now included in the default sequence. It will cause units to
be automatically started on installation, restarted on upgrade and stopped on removal for
every systemd user instance running on the system.

- Use of the dh_gconf command in override and hook targets now causes an error. The dh_gconf
command has been a no-op for years and was removed in debhelper 13.4.

- The dh sequencer will warn if the single-binary addon is implicitly activated to warn
maintainers of the pending compat 15 change in dh_auto_install.

Maintainers are urged to either explicitly activate the single-binary addon to preserve the
existing behaviour (e.g., by adding dh-sequence-single-binary to Build-Depends), or
explicitly passing --destdir to dh_auto_install if used and then passing --without single-
binary to dh (the latter to silence the warning).

The rationale for this change to avoid "surprises" when adding a second binary package later.
Previously, debhelper would silently change behaviour often resulting in empty binary
packages being uploaded to the archive by mistake. With the new behaviour, the single-binary
addon will detect the mismatch and warn the maintainer of what is about to happen.

v15 Ce niveau de compatibilité est encore en développement ; à utiliser avec précaution.

Changes from v14 are:

- The dh_auto_install tool no longer defaults to --destdir=debian/package for source packages
only producing a single binary. If this behaviour is wanted, the package should explicitly
activate the single-binary dh addon (e.g., by adding dh-sequence-single-binary to Build-
Depends) or pass --destdir to dh_auto_install.

REMARQUES

Prise en charge de plusieurs paquets binaires
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).

-a/--arch, -i/--indep ou aucune option de sélection (un simple appel « dh_X »)
Le paquet désactivé par le profil est silencieusement exclu de la sélection.

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.

-N paquet / --no-package paquet
Cette option est acceptée et ne fait rien.

-p paquet / --package paquet
Cette option est acceptée, mais debhelper n'agira pas sur le paquet.

Veuillez noter que cela n'a pas d'importance que le paquet soit activé ou désactivé par défaut.

Génération automatique des scripts Debian d’installation
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}");
}
}

Génération automatique des diverses dépendances.
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é.

Répertoires de construction du paquet
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.

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

VARIABLES D'ENVIRONNEMENT

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

DH_VERBOSE
Mettre cette variable à 1 valide le mode verbeux. Debhelper affichera chaque commande exécutée.
Valide aussi les journaux de construction bavards pour certains systèmes de construction comme
autoconf.

DH_QUIET
Mettre cette variable à 1 valide le mode silencieux. Debhelper n'affichera aucune commande appelant
le système de construction amont, et dh n'affichera aucune des sous-commandes appelées. En fonction
du système de construction amont, cela pourra le rendre encore plus silencieux. Cela facilite la
détection des messages importants, mais rend la sortie inutile en tant que journal de construction.
Cette valeur est ignorée si DH_VERBOSE est aussi positionnée.

DH_COMPAT
Indique temporairement le niveau de compatibilité avec lequel debhelper doit fonctionner. Cette
valeur supplante toute valeur précisée par Build-Depends sur debhelper-compat ou dans debian/compat.

DH_NO_ACT
Mettre cette variable à 1 pour activer le mode simulation (no-act).

DH_OPTIONS
Tous les outils de debhelper analyseront les arguments de la ligne de commande listés dans cette
variable avant toute option de commande (comme s'ils avaient été ajoutés au début des arguments de la
ligne de commande). Malheureusement, certains outils tiers peuvent ne pas prendre en compte cette
variable et ignoreront ces arguments.

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.

DH_ALWAYS_EXCLUDE
Si cette variable possède une valeur, elle sera ajoutée à l'option -X de toutes les commandes qui
admettent cette option. De plus, dh_builddeb fera un rm -rf pour chaque chose correspondant à la
valeur dans l'arbre de construction de paquet.

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.

DH_EXTRA_ADDONS
Les rajouts à dh indiqués seront exécutés lors de la séquence de commandes. Cela équivaut à les
indiquer avec le drapeau --with dans le fichier debian/rules. Les rajouts précédés de --without ne
seront pas exécutés, même s'ils sont indiqués dans cette variable d'environnement.

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.

DH_COLORS, DPKG_COLORS
Ces variables peuvent être utilisées pour contrôler comment les commandes de debhelper peuvent
utiliser la couleur dans leurs sorties textuelles. Les réglages peuvent être « always », « auto »
(par défaut) ou « never ».

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.

NO_COLOR
Si aucune demande explicite de couleur n'a été passée (par exemple, ni DH_COLORS, ni DPKG_COLORS
n'ont été configurées), la présence de cette variable d'environnement fera que le réglage des
couleurs par défaut sera « never ».

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.

CFLAGS, CPPFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS, FCFLAGS, LDFLAGS
Par défaut (dans tout niveau de compatibilité non obsolète), debhelper réglera automatiquement ces
paramètres en utilisant dpkg-buildflags(1) quand ils ne sont pas définis. S'il est nécessaire de
changer les paramètres par défaut, veuillez utiliser les fonctions de dpkg-buildflags(1) pour le
faire (par exemple, DEB_BUILD_MAINT_OPTIONS=hardening=all ou
DEB_CPPFLAGS_MAINT_APPEND=-DCUSTOM_MACRO=true) au lieu de configurer directement les variables
concrètes.

HOME, XDG_*
À partir du niveau de compatibilité 13, ces variables d'environnement sont réinitialisées avant
d'invoquer le système de construction amont à l'aide des outils dh_auto_*. Les variables HOME (pour
tout outil dh_auto_*) et XDG_RUNTIME_DIR (pour dh_auto_test seulement) seront réglées dans un
répertoire accessible en écriture. Toutes les autres variables et XDG_RUNTIME_DIR (sauf durant
dh_auto_test) seront vidées.

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.

DEB_BUILD_OPTIONS
Veuillez consulter "Paramètres pris en charge dans DEB_BUILD_OPTIONS" pour cet environnement.

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

DEB_MAINT_BUILD_OPTIONS
C'est une variable d'environnement spécifique à dpkg (voir par exemple dpkg-buildflags(1)). La suite
d'outils de debhelper l'ignore silencieusement.

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.

Paramètres pris en charge dans DEB_BUILD_OPTIONS
La suite d'outils de debhelper réagit aux paramètres suivants dans DEB_BUILD_OPTIONS.

dherroron=obsolete-compat-levels
C'est une valeur spécifique à debhelper.

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.

nostrip
Cette valeur changera le contenu des paquets .deb en construction. Les paquets .deb construits avec
ce réglage ne seront donc pas reproductibles bit à bit par rapport à une construction normale en cas
général.

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

nocheck
Cette valeur fera que les systèmes de construction officiels de debhelper ignoreront l'exécution des
suites de tests de l'amont.

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

nodoc
Cette valeur changera le contenu des paquets .deb en construction. Les paquets .deb construits avec
ce réglage ne seront donc pas reproductibles bit à bit par rapport à une construction normale en cas
général.

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.

noautodbgsym, noddebs
Le nom officiel est autodbgsym. La variante noddebs est acceptée pour des raisons historiques.

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

parallel=N
Cette valeur à permet debhelper d'utiliser jusqu'à N threads ou processus (soumis à des paramètres
comme --no-parallel et --max-parallel=M). Tous les outils de debhelper ne fonctionnent pas avec des
tâches parallèles et peuvent ignorer silencieusement la requête.

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.

terse
Cette valeur fera que les systèmes de construction officiels de debhelper configurent les
constructions de l'amont pour qu'elles soient laconiques (c'est-à-dire réduisent la verbosité de
leurs sorties). Cela est subordonné à la prise en charge par les systèmes de construction de l'amont
et de debhelper de ces fonctionnalités.

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

VOIR AUSSI

       /usr/share/doc/debhelper/examples/
           Un ensemble d'exemples de fichiers debian/rules qui utilisent debhelper.

       <http://joeyh.name/code/debhelper/>
           Le site internet de debhelper.

AUTEUR

       Joey Hess <joeyh@debian.org>

TRADUCTION

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

13.6ubuntu1                                        2022-02-07                                       debhelper(7)