debhelper - Ensemble d'outils regroupés sous le nom de
debhelper
dh_* [-v] [-a] [-i]
[--no-act] [-ppaquet] [-Npaquet]
[-Ptmpdir]
Debhelper facilite la construction des paquets Debian. La
philosophie qui sous-tend debhelper est de fournir une collection de petits
outils simples et facilement compréhensibles qui seront
exploités dans debian/rules pour automatiser les tâches
courantes liées à la construction des paquets, d'où un
travail allégé pour le responsable. Dans une certaine mesure,
cela signifie également que ces outils peuvent être
adaptés aux modifications éventuelles de la
Charte Debian. Les paquets qui utiliseront debhelper ne
nécessiteront qu'une simple reconstruction pour être conformes
aux nouvelles règles.
Un fichier debian/rules typique, exploitant debhelper,
appellera séquentiellement plusieurs des commandes de debhelper ou
bien utilisera dh(1) pour automatiser ce processus. Des exemples de
fichiers debian/rules qui exploitent debhelper se trouvent dans
/usr/share/doc/debhelper/examples/
Pour créer un nouveau paquet Debian en utilisant debhelper,
il suffit de copier un des fichiers d'exemple et de le modifier
manuellement. Il est possible également d'essayer le paquet
dh-make qui contient une commande dh_make automatisant partiellement
le processus. Pour se familiariser avec ces concepts, le paquet Debian
maint-guide contient un cours sur la construction d'un premier paquet
avec debhelper.
Sauf lorsque l'outil explicite le contraire, tous les outils
debhelper sont prévus pour être exécutés dans le
répertoire racine d'un paquet source désarchivé. Cela
leur permet de trouver les fichiers debian/control.
Voici la liste des commandes 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
- 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
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)
Si le nom d'un programme commence par dh_ et qu'il n'est
pas dans les listes ci-dessus, cela signifie qu'il ne fait pas partie de la
suite debhelper. Cependant, il devrait tout de même fonctionner comme
les autres programmes décrits dans cette page.
Beaucoup de commandes de debhelper utilisent des fichiers du
répertoire debian/ pour piloter leur fonctionnement. Outre les
fichiers debian/changelog et debian/control, qui se trouvent
dans tous les paquets, et pas seulement dans ceux qui emploient debhelper,
d'autres fichiers peuvent servir à configurer le comportement des
commandes spécifiques de debhelper. Ces fichiers sont, en principe,
nommés debian/paquet.toto (où paquet est, bien
sûr, à remplacer par le nom du paquet concerné).
Par exemple, dh_installdocs utilise un fichier
appelé debian/package.docs pour énumérer les
fichiers de documentation qu'il installera. Consulter les pages de manuel
des différentes commandes pour connaître le détail des
noms et des formats des fichiers employés. D'une façon
générale, ces fichiers de configuration
énumèrent les fichiers sur lesquels devra porter l'action,
à raison d'un fichier par ligne. Quelques programmes de debhelper
emploient des paires fichier/destination voire des formats
légèrement plus compliqués.
Veuillez noter que pour le premier (ou unique) paquet binaire
listé dans debian/control, debhelper utilisera
debian/toto lorsqu'il n'y a aucun fichier
debian/paquet.toto. Cependant, c'est une bonne
idée de garder le préfixe paquet. car
c'est plus explicite. Les principales exceptions sont les fichiers que
debhelper installe par défaut dans chaque paquet binaire lorsqu'il ne
trouve pas de préfixe (comme debian/copyright ou
debian/changelog).
Dans quelques rares cas, il peut être utile d'exploiter
différentes versions de ces fichiers pour des architectures ou des
systèmes d'exploitation différents. S'il existe des fichiers
appelés debian/paquet.toto.ARCH ou
debian/paquet.toto.OS, dans lesquels ARCH et OS
correspondent respectivement au résultat de
« dpkg-architecture -qDEB_HOST_ARCH »
ou de
« dpkg-architecture -qDEB_HOST_ARCH_OS »,
alors ils seront utilisés de préférence aux autres
fichiers plus généraux.
En général, ces fichiers de configuration sont
employés pour indiquer des listes de divers types de
fichiers : documentation, fichiers d'exemple à installer,
fichiers à déplacer et ainsi de suite. Lorsque cela se
justifie, dans des cas comme ceux-ci, il est possible d'employer, dans ces
fichiers, les jokers (wildcard) standards de l'interpréteur de
commandes (shell) (? et * et [..]). Des
commentaires peuvent être ajoutés dans ces fichiers :
les lignes commençant par # sont ignorées.
La syntaxe de ces fichiers est volontairement simple, pour les
rendre faciles à lire, à comprendre et à modifier.
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).
- La sortie sera utilisée exactement telle quelle. En particulier,
debhelper ne développera pas les jokers, ni ne supprimera
les commentaires de la sortie.
Si vous avez besoin de construire le paquet sur un système
de fichiers où l'on ne peut pas désactiver le bit
d'exécution, vous pouvez utiliser dh-exec(1) et son script
strip-output.
Tous les programmes de debhelper acceptent les options
suivantes.
- -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.
- --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.
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.
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 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.
- --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.
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.
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.
- 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
- Les changements par rapport à la version 8
sont :
- v10
- Les changements par rapport à la version 9
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
- 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.
Si une dépendance non versionnée est requise,
cela peut être obtenu en passant -VNone à la place.
Veuillez tout de même consulter dh_makeshlibs(1) pour
l'utilisation des dépendances non versionnées.
- L'option -s (--same-arch) est supprimée. Veuillez
utiliser -a (--arch) à la place.
- Appeler dh_clean -k provoque maintenant une erreur à la
place de l'avertissement d'obsolescence.
- L'option --no-restart-on-upgrade de dh_installinit a
été supprimée. Veuillez utiliser le nouveau nom
--no-stop-on-upgrade.
- Il y avait un bogue dans les fonctions doit (et équivalent)
de Debian::Debhelper::Dh_Lib qui créait un shell dans une
circonstance particulière. Ce bogue est maintenant supprimé
et provoquera une erreur de type « commande non
trouvée » dans les outils qui l'utilisaient.
- Les options --list-missing et --fail-missing de
dh_install ont été supprimées. Veuillez
utiliser dh_missing et ses options correspondantes, qui peuvent
aussi voir les fichiers installés par les autres outils.
- L'outil dh_installinit n'installe plus de configuration pour
upstart. À la place, il abandonnera la construction s'il trouve un
ancien fichier de configuration upstart. Cela pour rappeler au mainteneur
de s'assurer de correctement supprimer les anciens fichiers de
configuration livrés dans les anciennes versions du paquet.
- L'outil dh_installdeb valide basiquement quelques commandes
dpkg-maintscript-helper(1) et renvoie une erreur si la commande
semble incorrecte.
- Le comportement par défaut de dh_missing est maintenant
--list-missing.
- dh_makeshlibs passera maintenant les bibliothèques à
dpkg-gensymbols(1) si le binaire ELF a un SONAME (contenant
« .so »).
- dh_compress ne compresse plus les exemples (c'est-à-dire
tout ce qui est installé dans
</usr/share/doc/paquet/examples>).
- La séquence standard de dh comprend maintenant dh_dwz
et dh_installinitramfs par défaut. Cela rend les
séquences dwz et installinitramfs obsolètes et
elles échoueront avec une erreur. Si vous souhaitez sauter ces
commandes, veuillez insérer des cibles de réécriture
vides pour elles dans debian/rules (par exemple
override_dh_dwz:).
- Les systèmes de construction meson et autoconf ne
positionnent plus explicitement la variable --libexecdir, et
s'appuient donc sur le système de construction par défaut
– qui devrait être /usr/libexec (selon la
FHS 3.0, adoptée dans la Charte Debian 4.1.5).
Si un paquet amont particulier n'utilise pas la bonne valeur
par défaut, le paramètre peut souvent être
passé manuellement avec dh_auto_configure(1). Par
exemple :
override_dh_auto_configure:
dh_auto_configure -- --libexecdir=/usr/libexec
Remarquez le -- avant le paramètre
--libexecdir.
- 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.
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é.
Par défaut, tous les programmes de debhelper supposent que
le répertoire temporaire utilisé pour construire
l'arborescence des fichiers d'un paquet est debian/paquet.
Parfois, il peut être souhaitable d'utiliser un autre
répertoire temporaire. C'est obtenu grâce à l'attribut
-P. Par exemple, dh_installdocs -Pdebian/tmp utilisera
debian/tmp comme répertoire temporaire. Nota : L'usage
de -P implique que les programmes de debhelper ne construisent qu'un
seul paquet à la fois. De ce fait, si le paquet source
génère plusieurs paquets binaires, il faudra employer
également le paramètre -p pour préciser l'unique
paquet binaire à construire.
Debhelper prend en charge la construction des udebs. Pour
créer un udeb avec debhelper, il faut ajouter
« Package-Type: udeb » aux lignes
de paquet dans debian/control. Debhelper essayera de construire des
udebs, conformément aux règles de l'installateur Debian, en
suffixant les fichiers de paquets générés avec
.udeb, en n'installant aucune documentation dans un udeb, en omettant
les scripts preinst, postrm, prerm et
config, etc.
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
- 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.
- 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.
- /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.
Joey Hess <joeyh@debian.org>
Cette traduction est maintenue à l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'équipe francophone
de traduction de Debian.
Veuillez signaler toute erreur de traduction en écrivant
à <debian-l10n-french@lists.debian.org> ou par un rapport de
bogue sur le paquet debhelper.
Vous pouvez toujours avoir accès à la version
anglaise de ce document en utilisant la commande « man -L C
<section> <page_de_man> ».