Ubuntu Manpages

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 et debian/compat.

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

Construire automatiquement un paquet
Faire le ménage automatiquement après une construction de paquet
Configurer automatiquement un paquet préalablement à sa construction
Lancer automatiquement make install ou équivalent
Exécuter automatiquement le jeu d'essai d'un paquet
Installer les fichiers de personnalisation de rapports de bogue dans les répertoires des paquets construits
Construire des paquets binaires Debian
Nettoyer les répertoires de construction du paquet
Compresser les fichiers dans le répertoire de construction du paquet et modifier les liens symboliques en conséquence
Ajuster les droits sur les fichiers du répertoire de construction du paquet
Installer les fichiers par défaut de GConf et inscrire les schémas
Produire et installer le fichier de contrôle
Mettre à jour les caches des icônes Freedesktop
Installer les fichiers dans le répertoire de construction du paquet
Installer et inscrire les catalogues SGML
Installer les journaux de suivi des modifications (changelog) dans les répertoires de construction du paquet
Installer les scripts cron dans etc/cron.*
Installer des fichiers dans le répertoire DEBIAN
Installer les fichiers utilisés par debconf dans les répertoires de construction du paquet
Créer des sous-répertoires dans le répertoire de construction du paquet
Installer la documentation dans le répertoire de construction du paquet
Inscrire un paquet additionnel Emacs
Installer les fichiers d'exemples dans le répertoire de construction du paquet
Installer les accroches (hooks) if-up et if-down
Installer les fichiers info
Installer les fichiers de service « init » dans le répertoire de construction du paquet
Installer les fichiers de règles de vérification des journaux (logcheck rulefiles) dans etc/logcheck/
Installer les fichiers de configuration de la rotation des journaux (logrotate)
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
Installer les fichiers « mime » dans le répertoire de construction du paquet
Inscrire les modules du noyau
Installer les fichiers de support de PAM
Installer les fichiers ppp.ip-up et ppp.ip-down
Installer les fichiers de règles udev
Inscrire un gestionnaire de fenêtres (window manager)
Inscrire les polices de caractères graphiques (X fonts)
Créer les liens symboliques dans le répertoire de construction du paquet
Installer les fichiers « override » de lintian dans le répertoire de construction du paquet
Énumérer les paquets binaires que debhelper va traiter
Créer automatiquement le fichier shlibs et exécuter dpkg-gensymbols
Créer le fichier DEBIAN/md5sums
Déplacer des fichiers depuis debian/tmp dans des sous-paquets
Déterminer les dépendances Perl et fait le ménage après MakeMaker
Faire le ménage en vue de construire un paquet Debian
Déterminer les dépendances envers les bibliothèques partagées
Dépouiller les exécutables, les bibliothèques partagées, et certaines bibliothèques statiques
Activer ou désactiver les fichiers unit de systemd
Démarrer/arrêter/redémarrer des fichiers unit de systemd
Vérifier le répertoire avant de construire un paquet Debian
Vérifier que le paquet est construit avec les droits nécessaires du superutilisateur (root)
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.

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.

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.

Tous les programmes de debhelper acceptent les options suivantes.

Mode verbeux : affiche toutes les commandes qui modifient le répertoire de construction du paquet.
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.
Construit tous les paquets dépendants de l'architecture DEB_HOST_ARCH.
Construit tous les paquets indépendants de l'architecture.
Construit le paquet nommé paquet. Cette option peut être répétée afin de faire agir debhelper sur plusieurs paquets.
Alias obsolète pour -a.

This option is removed in compat 12.

Exclut le paquet indiqué du processus de construction, même si l'option -a, -i ou -p l'impliquait.
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 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

Utilise le répertoire tmpdir pour construire les paquets. Sinon, par défaut, le répertoire utilisé est debian/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.
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.

Ne pas modifier les scripts de maintenance du paquet (postinst, postrm, etc.)
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.
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_*.

Oblige à utiliser le processus de construction indiqué au lieu de tenter de déterminer automatiquement celui qui pourrait être utilisable pour le paquet.
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.
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.

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.

As an optimization, dh will try to avoid passing these options to subprocesses, if they are unnecessary and the only options passed. Notably this happens when DEB_BUILD_OPTIONS does not have a parallel parameter (or its value is 1).

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.

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.

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. Le niveau de compatibilité est spécifié dans le fichier debian/compat qui doit être présent.

Pour indiquer à debhelper le niveau de compatibilité à utiliser il faut placer un nombre dans debian/compat. Par exemple, pour exploiter la version 11 :

 % echo 11 > 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 11 de compatibilité, debian/control devra contenir :

 Build-Depends: debhelper (>= 11)

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 :

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

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.

Ce mode est déconseillé.

Les changements par rapport à la version 6 sont :
  • dh_install cherchera récursivement les fichiers dans debian/tmp s'il ne les trouve pas dans le répertoire courant (ou dans le répertoire indiqué par --sourcedir). Cela permet à dh_install d'interopérer avec dh_auto_install, qui place les fichiers dans debian/tmp, sans nécessiter de paramètres particuliers.
  • dh_clean lit le répertoire debian/clean et supprime les fichiers qui y sont mentionnés.
  • dh_clean supprime les fichiers *-stamp.
  • dh_installchangelogs déterminera à quel fichier correspond le changelog amont si rien n'est indiqué.

Ce mode est déconseillé.

Les changements par rapport à la version 7 sont :
  • Les commandes échoueront plutôt que de produire une alerte lorsqu'elles recevront des options inconnues.
  • dh_makeshlibs va exécuter le programme dpkg-gensymbols sur toutes les bibliothèques partagées qu'il génère pour les fichiers shlibs. -X peut alors être utilisé pour exclure certaines bibliothèques. En outre, les bibliothèques rangées à des emplacements inhabituels que pkg-gensymbols n'aurait pas traitées avant qu'elles ne lui soient transmises, induisent un changement de comportement qui peut causer l'échec de la construction de certains paquets.
  • dh exige que la séquence à exécuter soit indiquée en tant que premier paramètre. Tous les commutateurs doivent venir après. C'est-à-dire qu'il faut écrire « dh $@ --toto », et non « dh --toto $@ »
  • dh_auto_* utilise préférentiellement Module::Build de Perl au lieu de Makefile.PL.

Ce mode est déconseillé.

Les changements par rapport à la version 8 sont :
  • Prise en charge multiarchitecture. En particulier dh_auto_configure passe les répertoires multiarchitectures à autoconf dans --libdir et --libexecdir.
  • dh connaît les dépendances classiques entre les cibles de debian/rules. Donc « dh binary » exécutera toutes les cibles build, build-arch, build-indep, install, etc., présentes dans le fichier rules. Il n'est pas nécessaire de définir une cible binary avec des dépendances explicites sur les autres cibles.
  • dh_strip compresse les fichiers de symboles de mise au point pour réduire la taille d'installation des paquets -dbg.
  • dh_auto_configure n'inclut pas le nom du paquet source dans --libexecdir en utilisant autoconf.
  • dh n'active pas --with=python-support par défaut.

    (Obsolète puisque l'outil dh_pysupport a été retiré de Debian Stretch. Depuis debhelper 10.3, dh n'active plus cette séquence quel que soit le niveau de compatibilité)

  • Tous les programmes debhelper dh_auto_* et dh configurent les variables d'environnement renvoyées par dpkg-buildflags, sauf si elles sont déjà configurées.
  • dh_auto_configure passe les CFLAGS, CPPFLAGS et LDFLAGS de dpkg-buildflags à Makefile.PL et Build.PL de Perl.
  • dh_strip place les symboles de mise au point séparés à un endroit en fonction de leur identifiant de construction (build-id).
  • Les fichiers de configuration exécutables de debhelper sont exécutés et leur sortie est utilisée comme configuration.
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.
  • La commande dh n'acceptera aucun des paramètres obsolètes de « manual sequence control » (--before, --after, etc.). Veuillez utiliser les cibles de réécritures à la place.
  • La commande dh n'utilisera plus les fichiers journaux pour enregistrer quelles commandes ont été exécutées. La commande dh se souvient toujours si la séquence « build » a été effectuée et l'omet si c'est le cas.

    Les principales conséquences de cela sont :

  • Il est maintenant plus facile de déboguer les séquences install et binary parce qu'elles peuvent maintenant être facilement re-exécutées (sans avoir à refaire un cycle complet de « clean & rebuild »)
  • La principale précaution est que dh_* enregistre uniquement ce qui s'est passé dans une unique cible de réécriture. Lorsque tous les appels à une commande dh_cmd donnée arrivent dans la même cible de réécriture, tout fonctionnera comme avant.

    Exemple de ce qui pourrait mal se passer :

      override_dh_foo:
    dh_foo -pmon_paquet
  override_dh_bar:
    dh_bar
    dh_foo --remaining

    Dans ce cas, l'appel à dh_foo --remaining inclura aussi mon_paquet, car dh_foo -pmon_paquet a été exécuté dans une cible de réécriture différente. Ce problème n'est pas limité à --remaining et concerne aussi -a, -i, etc.

  • À présent, la commande dh_installdeb échappe les caractères du shell dans les lignes du fichier de config maintscript. C'était l'intention originale mais cela n'a jamais fonctionné correctement et les paquets ont commencé à compter sur l'échappement incomplet (p. ex. en encadrant les noms de fichiers de guillemets).
  • La commande dh_installinit utilise maintenant --restart-after-upgrade par défaut. Les paquets nécessitant le comportement précédent devraient utiliser l'option --no-restart-after-upgrade.
  • La séquence autoreconf est maintenant activée par défaut. Veuillez passer l'option --without autoreconf à dh si cela n'est pas voulu pour certains paquets.
  • La séquence systemd est maintenant activée par défaut. Veuillez passer l'option --without systemd à dh si cela n'est pas voulu pour certains paquets.
C'est la version dont l'usage est recommandé.

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.

    Please note that the dh_installsystemd tool has a slightly different behaviour in some cases (e.g. when using the --name parameter).

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

    Migration note: A bug in debhelper 11 up to 11.1.5 made dh_installinfo incorrectly ignore --sourcedir.

  • The perl-makemaker and perl-build build systems no longer pass -I. to perl. Packages that still need this behaviour can emulate it by using the PERL5LIB environment variable. E.g. by adding export PERL5LIB=. in their debian/rules file (or similar).
  • 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és 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 essaient maintenant de deviner le « paquet principal » pour un paquet de documentation donné (par exemple paquet-doc aura paquet comme paquet principal si ce dernier existe). Si un paquet principal est trouvé, la plupart de la documentation sera installée par défaut dans /usr/share/doc/paquet-principal, comme recommandé par la Charte Debian §12.3 depuis la version 3.9.7. Les exceptions à cela incluent les fichiers copyright et changelog.

    L'option --doc-main-package peut être utilisée si la détection automatique est insuffisante.

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

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

Les changements par rapport à la version 11 sont :

  • 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.
  • The dh_missing tool will now default to --list-missing.
  • The dh_makeshlibs tool will now only pass libraries to dpkg-gensymbols(1) if the ELF binary has a SONAME (containing ".so").
  • The dh_compress tool no longer compresses examples (i.e. anything installed in </usr/share/doc/package/examples>.)

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

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.

Cette option est acceptée et ne fait rien.
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 ».

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.
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.
Indique temporairement le niveau de compatibilité avec lequel debhelper doit fonctionner. Cette valeur supplante toute valeur précisée dans debian/compat.
Mettre cette variable à 1 pour activer le mode simulation (no-act).
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.

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.

If set, this adds the specified dh addons to be run in the appropriate places in the sequence of commands. This is equivalent to specifying the addon to run with the --with flag in the debian/rules file. Any --without calls specifying an addon in this environment variable will not be run.

This is intended to be used by downstreams or specific local configurations that require a debhelper addon to be run during multiple builds without having to patch a large number of rules file. If at all possible, this should be avoided in favor of a --with flag in the rules file.

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