debhelper(7) Debhelper debhelper(7)
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
Verbose mode: show commands that modify the package build
directory.
Note that verbose mode may also output other "internal" commands
that do not directly affect the package build directory.
--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
By default, dh(1) will compute several environment variables (e.g.
by using dpkg-buildflags(1)) and cache them to avoid having all
dh_auto_* tool recompute them.
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é).
Note that debhelper does not provide debhelper-compat for experimental
or beta compatibility levels; packages experimenting with those
compatibility levels should use debian/compat (or, if only for selected
commands, DH_COMPAT).
Prior versions of debhelper required specifying the compatibility level
in the file debian/compat, and current debhelper still supports this
for backward compatibility. To use this method, the debian/compat file
should contain the compatibility level as a single number, and no other
content. If you specify the compatibility level by this method, your
package will also need a versioned build dependency on a version of the
debhelper package equal to (or greater than) the compatibility level
your package uses. So, if you specify compatibility level 13 in
debian/compat, ensure debian/control has:
Build-Depends: debhelper (>= 13~)
Note that you must use either the build-dependency on debhelper-compat
or the debian/compat file. Whenever possible, the debhelper-compat
build-dependency is recommended.
If needed be, the DH_COMPAT environment variable can be used to
override the compat level for a given command. The feature is mostly
useful for either temporarily upgrading a few commands to a new compat
level or keeping a few commands on a lower compat level. The feature is
best used sparingly as it effectively introduces special-cases into the
debian/rules file that may be surprising to maintainers or reviewers
(or, in the long term, to yourself).
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
The list of supported compatibility levels and the related upgrade
check list has moved to debhelper-compat-upgrade-checklist(7).
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
Set to a non-empty value to enable verbose mode. Please see the -v
/ --verbose option for details.
DH_QUIET
Set to a non-empty value to enable quiet mode. Debhelper will not
output commands calling the upstream build system nor will dh print
which subcommands are called and depending on the upstream build
system might make that more quiet, too. This makes it easier to
spot important messages but makes the output quite useless as
buildd log.
Ignored if DH_VERBOSE is also set or -v / --verbose is passed.
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_BUILD_MAINT_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.
notrimdch
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.
This value will cause dh_installchangelogs(1) to act as if it had
been passed the --no-trim option, forcing it to forgo removing
older entries from changelogs.
noautodbgsym, noddebs
Le nom officiel est noautodbgsym. 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.
This value affects most dh_auto_* tools directly. For commands
provided by the debhelper package, it also causes the tools to act
like the DH_QUIET environment variable was non-empty.
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
debhelper-compat-upgrade-checklist(7)
List of supported compat levels and an upgrade checklist for each
of them.
/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.11.4 2023-01-02 debhelper(7)
Generated by dwww version 1.15 on Sat Jun 29 01:44:46 CEST 2024.