Provided by: debhelper_9.20160115ubuntu3_all 
NOM
debhelper - Ensemble d'outils regroupés sous le nom de debhelper
SYNOPSIS
dh_* [-v] [-a] [-i] [-s] [--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.
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_fixperms(1)
Ajuster les droits sur les fichiers du répertoire de construction du paquet
dh_gconf(1)
Installer les fichiers par défaut de GConf et inscrire les schémas
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_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_testdir(1)
Vérifier le répertoire avant de construire un paquet Debian
dh_testroot(1)
Vérifier que le paquet est construit par le 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_desktop(1)
Obsolète, ne pas l'utiliser
dh_installmanpages(1)
Ancien programme d'installation des pages de manuel (obsolète)
dh_scrollkeeper(1)
Obsolète, ne pas l'utiliser
dh_suidregister(1)
Programme d'inscription suid (obsolète)
dh_undocumented(1)
Programme de création de liens symboliques vers « undocumented.7 » (obsolète, ne pas
l'utiliser)
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.
Nota : pour le premier (ou le seul) paquet binaire énuméré dans le fichier debian/control,
debhelper exploitera debian/toto quand aucun fichier debian/paquet.toto n'est présent.
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 gardée très simple pour les rendre faciles à
lire, comprendre et modifier. Si vous préférez la puissance et la complexité, vous pouvez
rendre le fichier exécutable, et écrire un programme qui affiche n'importe quel contenu
approprié à la situation. Dans ce cas, la sortie n'est plus traitée pour développer les
jokers (wildcards) ou supprimer les commentaires.
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.
-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
Cette option était plus intelligente que l'option -a, mais l'option -a est maintenant
tout aussi intelligente.
-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.
--ignore=fichier
Ignore le fichier indiqué. Cela peut être utilisé si debian/ contient un fichier de
configuration debhelper avec une commande qui ne doit pas être prise en compte. Nota :
debian/compat, debian/control, et debian/changelog ne peuvent pas être ignorés, mais
il n'existe aucune raison valable de les ignorer.
Par exemple, si vous récupérez en amont un fichier debian/init que vous ne voulez pas
que dh_installinit installe, utilisez --ignore=debian/init
-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.
-Dré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.
-B[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 la version 10 (ou supérieure), et la désactive
(--no-parallel) dans les autres versions.
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.
--list, -l
Liste tous les processus de construction supportés 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 précisera à debhelper
le niveau de compatibilité qu'il doit employer, ce qui modifiera son comportement de
diverses manières.
Pour indiquer à debhelper le niveau de compatibilité à utiliser il faut placer un nombre
dans debian/compat. Par exemple, pour exploiter la version 9 :
% echo 9 > debian/compat
Le paquet nécessitera aussi une version de debhelper dans les dépendances de construction
au moins égale au niveau de compatibilité utilisée pour la construction du paquet. Ainsi,
si le paquet emploie le niveau 9 de compatibilité, debian/control devra contenir :
Build-Depends: debhelper (>= 9)
Sauf indication contraire, toute la documentation de debhelper suppose l'utilisation du
niveau de compatibilité le plus récent, et, dans la plupart des cas ne précise pas si le
comportement est différent avec les niveaux de compatibilité antérieurs. De ce fait, si le
niveau de compatibilité le plus récent n'est pas celui utilisé, il est fortement conseillé
de lire les indications ci-dessous qui exposent les différences dans les niveaux de
compatibilité antérieurs.
Les niveaux de compatibilité sont les suivants :
v3 C'est le niveau de compatibilité le plus bas pris en charge.
Ce mode est déconseillé.
v4 Les changements par rapport à la version 3 sont :
- dh_makeshlibs -V n'inclura pas la partie Debian du numéro de version dans la
ligne de dépendance produite dans le fichier shlibs.
- Il est fortement conseillé de mettre le nouveau ${misc:Depends} dans
debian/control pour compléter le champs ${shlibs:Depends}.
- dh_fixperms rendra exécutables tous les fichiers des répertoires bin/ et
etc/init.d.
- dh_link corrigera les liens existants pour les rendre conformes à la Charte
Debian.
Ce mode est déconseillé.
v5 Les changements par rapport à la version 4 sont :
- Les commentaires sont ignorés dans les fichiers de configuration de debhelper.
- dh_strip --dbg-package indique maintenant le nom du paquet qui doit recevoir
les symboles de mise au point et non les paquets d'où proviennent ces
symboles.
- dh_installdocs saute l'installation des fichiers vides.
- dh_install génère des erreurs si les jokers (wildcards) ne correspondent à
rien.
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.
- dh_builddeb, préalablement, 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. Préalablement, il refusait en silence de
le faire.
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é.
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.
v9 C'est la version dont l'usage est recommandé.
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.
- 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 Ce niveau de compatibilité est encore en développement ; à utiliser avec précaution.
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 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 dehelper, mais pourrait faire apparaître des
bogues dans les commandes qui ne sont pas incluses avec debhelper.
- 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 supportent. Cela peut être désactivé en utilisant l'option
--no-parallel ou en passant la valeur 1 à l'option --max-parallel.
- The dh command will not accept any of the deprecated "manual sequence control"
parameters (--before, --after, etc.). Please migrate to use override targets
instead.
- The dh command will no longer use log files to track which commands have been
run. The dh command still keeps track of whether it already ran the "build"
sequence and skip it if it did.
The main affects of this are:
- With this, it is now easier to debug the install or/and binary sequences
because they can now trivially be re-run (without having to do a full
"clean and rebuild" cycle)
- The main caveat is that dh_* now only keeps track of what happened in a
single override target. When all the calls to a given dh_cmd command
happens in the same override target every thing will work as before.
Example of where it can go wrong:
override_dh_foo:
dh_foo -pmy-pkg
override_dh_bar:
dh_bar
dh_foo --remaining
In this case, the call to dh_foo --remaining will also include my-pkg,
since dh_foo -pmy-pkg was run in a separate override target. This issue is
not limited to --remaining, but also includes -a, -i, etc.
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 de construction 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>).
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 dans debian/compat.
DH_NO_ACT
Mettre cette variable à 1 pour activer le mode simulation (no-act).
DH_OPTIONS
Tout ce qui est indiqué dans cette variable sera passé en argument à toutes les
commandes debhelper.
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.
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
Valéry Perrin <valery.perrin.debian@free.fr> le 17 septembre 2005. Dernière mise à jour le
3 avril 2011.
L'équipe de traduction a fait le maximum pour réaliser une adaptation française de
qualité.
Cette traduction est gérée dynamiquement par po4a. Certains paragraphes peuvent,
éventuellement, apparaître en anglais. Ils correspondent à des modifications ou des ajouts
récents du mainteneur, non encore incorporés dans la traduction française.
La version originale anglaise de ce document est toujours consultable via la commande
man -L en nom_du_man.
N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans
cette page de manuel.