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 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_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 debhelper sont obsolètes et ne devraient plus être utilisées.

       dh_gconf(1)
           Installer les fichiers par défaut de GConf et inscrire les schémas (obsolète)

       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 in debhelper config files
In compatibility level 13 and later, it is possible to use simple substitutions in some
debhelper config files (particularly, the configuration files for dh_install(1)).

All substitution variables are of the form ${foo} and the braces are mandatory. Variable
names are case-sensitive and consist of alphanumerics (a-zA-Z0-9), hyphens (-),
underscores (_), and colons (:). The first character must be an alphanumeric.

If you need a literal dollar sign that cannot trigger a substitution, you can either use
the ${Dollar} substitution or the sequence ${}.

The following expansions are available:

DEB_HOST_*, DEB_BUILD_*, DEB_TARGET_*
Expands to the relevant dpkg-architecture(1) value (similar to dpkg-architecture
-qVARIABLE_HERE).

When in doubt, the DEB_HOST_* variant is the one that will work both for native and
cross builds.

For performance reasons, debhelper will attempt to resolve these names from the
environment first before consulting dpkg-architecture(1). This is mostly mentioned for
completeness as it will not matter for most cases.

Dollar
Expands to a single literal $-symbol. This symbol will never be considered part of a
substitution variable. That is:

# Triggers an error
${NO_SUCH_TOKEN}
# Expands to the literal value "${NO_SUCH_TOKEN}"
${Dollar}{NO_SUCH_TOKEN}

This variable equivalent to the sequence ${} and the two can be used interchangeably.

Newline, Space, Tab
Expands to a single ASCII newline, space and tab respectively.

This can be useful if you need to include a literal whitespace character (e.g. space)
where it would otherwise be stripped or used as a separator.

env:NAME
Expands to the environment variable NAME. The environment variable must be set (but
can be set to the empty string).

Note that all variables must expand to a defined value. As an example, if debhelper sees
${env:FOO}, then it will insist that the environment variable FOO is set (it can be set to
the empty string).

Substitution limits

To avoid infinite loops and resource exhaustion, debhelper will stop with an error if the
text contains many substitution variables (50) or they expand beyond a certain size (4096
characters or 3x length of the original input - whichever is bigger).

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

• In compatibility level 13+, the output will be subject to substitutions (see
"Substitutions in debhelper config files") where the tool support these. Remember to
be careful if your generator also provides substitutions as this can cause unnecessary
confusion.

Otherwise, the output will be used exactly as-is. Notably, debhelper will not expand
wildcards or strip comments or strip whitespace in the output.

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.

Pass none as buildsystem to disable auto-selection.

-Ddirectory, --sourcedir=directory, --sourcedirectory=directory
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.

-B[directory], --builddir[=directory], --builddirectory[=directory]
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
By default, dh(1) will compute several environment (e.g. by using dpkg-buildflags(1))
and cache them to avoid having all dh_auto_* tool recompute them.

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

Without --reload-all-buildenv-variables in the second call to dh_auto_configure(1),
the change in DEB_CFLAGS_MAINT_APPEND would be ignored as dh_auto_configure(1) would
use the cached value of CFLAGS set by dh(1).

This option is only available with debhelper (>= 12.7~) when the package uses
compatibility level 9 or later.

--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 12, assurez-vous
d'indiquer dans debian/control :

Build-Depends: debhelper-compat (= 12)

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 12 dans debian/compat, assurez-vous que le
fichier debian/control contient :

Build-Depends: debhelper (>= 12~)

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 :

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

Ce mode est déconseillé.

v6 Les changements par rapport à la version 5 sont :

- Les commandes qui génèrent des lignes de codes de maintenance les mettront
dans l'ordre inverse dans les scripts prerm et postrm.

- dh_installwm installera un lien vers une page de manuel esclave pour
x-window-manager.1.gz s'il voit la page de manuel dans le répertoire
usr/share/man/man1 du répertoire de construction du paquet.

- Auparavant, dh_builddeb ne supprimait pas les associations créées avec
DH_ALWAYS_EXCLUDE s'il était configuré sur une liste d'éléments tels que
CVS:.svn:.git. Maintenant il le fait.

- dh_installman permet d'écraser les pages de manuel existantes dans le
répertoire de construction du paquet. Auparavant, il refusait en silence de le
faire.

Ce mode est déconseillé.

v7 Les changements par rapport à la version 6 sont :

- dh_install cherchera récursivement les fichiers dans debian/tmp s'il ne les
trouve pas dans le répertoire courant (ou dans le répertoire indiqué par
--sourcedir). Cela permet à dh_install d'interopérer avec dh_auto_install qui
place les fichiers dans debian/tmp, sans nécessiter de paramètres
particuliers.

- dh_clean lit le répertoire debian/clean et supprime les fichiers qui y sont
mentionnés.

- dh_clean supprime les fichiers *-stamp.

- dh_installchangelogs déterminera à quel fichier correspond le changelog amont
si rien n'est indiqué.

Ce mode est déconseillé.

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.

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.

Retroactively applied to earlier compat levels: dh no longer accepts any of
these since 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_foo:
dh_foo -pmon_paquet

override_dh_bar:
dh_bar
dh_foo --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 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 This mode is discouraged.

The compat 11 is discouraged for new packages as it suffers from feature interaction
between dh_installinit and dh_installsystemd causing services to not run correctly in
some cases. Please consider using compatibility mode 10 or 12 instead. More details
about the issue are available in Debian#887904 and
<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 C'est la version dont l'usage est recommandé.

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.

If an unversioned dependency in the shlibs file is wanted, this can be
obtained by passing -VNone instead. However, please see dh_makeshlibs(1) for
the caveat of unversioned dependencies.

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

- dh_installdeb n'installe plus le fichier conffiles fournit par le responsable.
Ce fichier est obsolète depuis le niveau de compatibilité 3, lorsque
dh_installdeb a commencé à calculer automatiquement le conffiles résultant du
fichier control.

- 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 Ce niveau de compatibilité est encore en développement ; à utiliser avec précaution.

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.

- All debhelper like tools based on the official debhelper library (including dh
and the official dh_* tools) no longer accepts abbreviated command parameters.
At the same time, dh now optimizes out calls to redundant dh_* helpers even
when passed long command line options.

- The ELF related debhelper tools (dh_dwz, dh_strip, dh_makeshlibs,
dh_shlibdeps) are now only run for arch dependent packages by default (i.e.
they are excluded from *-indep targets and are passed -a by default). If you
need them for *-indep targets, you can add an explicit Build-Depends on dh-
sequence-elf-tools.

- The third-party gradle build system (from gradle-debian-helper package) now
runs the upstream-provided test suite automatically. To suppress such
behavior, override dh_auto_test.

- The dh_installman tool now aborts if it sees conflicting definitions of a
manpage. This typically happens if the upstream build system is installing a
compressed version and the package lists an uncompressed version of the
manpage in debian/package.manpages. Often the easiest fix is to remove the
manpage from debian/package.manpages (assuming both versions are identical).

- The dh_auto_* helpers now resets the environment variables HOME and common
XDG_* variable. HOME and XDG_RUNTIME_DIR are each set to a distinct writable
directory. The rest of the environment variables are cleared.

- The dh command will now error if an override or hook target for an obsolete
command are present in debian/rules (e.g. override_dh_systemd_enable:).

- The dh_missing command will now default to --fail-missing. This can be
reverted to a non-fatal warning by explicitly passing --list-missing like it
was in compat 12.

If you do not want the warning either, please omit the call to dh_missing. If
you use the dh command sequencer, then you can do this by inserting the an
empty override target in the debian/rules file of the relevant package. As an
example:

# Disable dh_missing
override_dh_missing:

- The dh command sequencer now runs dh_installtmpfiles in the default sequence.
The dh_installtmpfiles takes over handling of tmpfiles.d configuration files.
Related functionality in dh_installsystemd is now disabled.

Note that dh_installtmpfiles responds to debian/package.tmpfiles where
dh_installsystemd used a name without the trailing "s".

- Many dh_* tools now support limited variable expansion via the ${foo} syntax.
In many cases, this can be used to reference paths that contain either spaces
or dpkg-architecture(1) values. While this can reduce the need for dh-exec(1)
in some cases, it is not a replacement dh-exec(1) in general. If you need
filtering, renaming, etc., the package will still need dh-exec(1).

Please see "Substitutions in debhelper config files" for syntax and available
substitution variables. To dh_* tool writers, substitution expansion occurs as
a part of the filearray and filedoublearray functions.

- The dh command sequencer will now skip all hook and override targets for
dh_auto_test, dh_dwz and dh_strip when DEB_BUILD_OPTIONS lists the relevant
nocheck / nostrip options.

Any package relying on these targets to always be run should instead move
relevant logic out of those targets. E.g. non-test related packaging code from
override_dh_auto_test would have to be moved to execute_after_dh_auto_build or
execute_before_dh_auto_install.

- The cmake buildsystem now passes -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON to
cmake(1) to speed up automatic installation process. If for some reason you
need previous behavior, override the flag:

dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...

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

Les variables d'environnement suivantes peuvent influencer le comportement de debhelper.
Il est important de noter que celles-ci doivent être des variables existantes pour que
cela fonctionne correctement (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
All debhelper tools will parse command line arguments listed in this variable before
any command option (as if they had been prepended to the command line arguments).
Unfortunately, some third-party provided tools may not support this variable and will
ignore these command line 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
These variables can be used to control whether debhelper commands should use colors in
their textual output. Can be set to "always", "auto" (the default), or "never".

Note that DPKG_COLOR also affects a number of dpkg related tools and debhelper uses it
on the assumption that you want the same color setting for dpkg and debhelper. In the
off-hand chance you want different color setting for debhelper, you can use DH_COLORS
instead or in addition to DPKG_COLORS.

NO_COLOR
If no explicit request for color has been given (e.g. DH_COLORS and DPKG_COLORS are
both unset), the presence of this environment variable cause the default color setting
to be "never".

The variable is defined according to <https://no-color.org/>. In this project, the
environment variables (such as DH_COLORS) are considered an explicit request for
color.

CFLAGS, CPPFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS, FCFLAGS, LDFLAGS
By default (in any non-deprecated compat level), debhelper will automatically set
these flags by using dpkg-buildflags(1), when they are unset. If you need to change
the default flags, please use the features from dpkg-buildflags(1) to do this (e.g.
DEB_BUILD_MAINT_OPTIONS=hardening=all or
DEB_CPPFLAGS_MAINT_APPEND=-DCUSTOM_MACRO=true) rather than setting the concrete
variable directly.

HOME, XDG_*
In compat 13 and later, these environment variables are reset before invoking the
upstream build system via the dh_auto_* helpers. The variables HOME and
XDG_RUNTIME_DIR will be set to a writable directory. The remaining variables will be
cleared.

The directories will be created as empty directories but they will be reused between
calls to dh_auto_*. Any content will persist until explicitly deleted or dh_clean.

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