Manpages

dh_installmanpages(1)

Ancien programme d’installation des pages de manuel (obsolète)

Autres commandes
Si le nom d’un programme commence par dh_ et qu’il n’est pas dans les listes ci-dessus, cela signifie qu’il ne fait pas partie de la suite debhelper. Cependant, il devrait tout de même fonctionner comme les autres programmes décrits dans cette page.

FICHIERS DE CONFIGURATION DE DEBHELPER

Beaucoup de commandes de debhelper utilisent des fichiers du répertoire debian/ pour piloter leur fonctionnement. Outre les fichiers debian/changelog et debian/control, qui se trouvent dans tous les paquets, et pas seulement dans ceux qui emploient debhelper, d’autres fichiers peuvent servir à configurer le comportement des commandes spécifiques de debhelper. Ces fichiers sont, en principe, nommés debian/paquet.toto (où paquet est, bien sûr, à remplacer par le nom du paquet concerné).

Par exemple, dh_installdocs utilise un fichier appelé debian/package.docs pour énumérer les fichiers de documentation qu’il installera. Consulter les pages de manuel des différentes commandes pour connaître le détail des noms et des formats des fichiers employés. D’une façon générale, ces fichiers de configuration énumèrent les fichiers sur lesquels devra porter l’action, à raison d’un fichier par ligne. Quelques programmes de debhelper emploient des paires fichier/destination voire des formats légèrement plus compliqués.

Veuillez noter que pour le premier (ou unique) paquet binaire listé dans debian/control, debhelper utilisera debian/toto lorsqu’il n’y a aucun fichier debian/paquet.toto. Cependant, c’est une bonne idée de garder le préfixe paquet. car c’est plus explicite. Les principales exceptions sont les fichiers que debhelper installe par défaut dans chaque paquet binaire lorsqu’il ne trouve pas de préfixe (comme debian/copyright ou debian/changelog).

Dans quelques rares cas, il peut être utile d’exploiter différentes versions de ces fichiers pour des architectures ou des systèmes d’exploitation différents. S’il existe des fichiers appelés debian/paquet.toto. ARCH ou debian/paquet.toto. OS , dans lesquels ARCH et OS correspondent respectivement au résultat de « dpkg-architecture -qDEB_HOST_ARCH » ou de « dpkg-architecture -qDEB_HOST_ARCH_OS », alors ils seront utilisés de préférence aux autres fichiers plus généraux.

En général, ces fichiers de configuration sont employés pour indiquer des listes de divers types de fichiers : documentation, fichiers d’exemple à installer, fichiers à déplacer et ainsi de suite. Lorsque cela se justifie, dans des cas comme ceux-ci, il est possible d’employer, dans ces fichiers, les jokers (wildcard) standards de l’interpréteur de commandes (shell) (? et * et [..]). Des commentaires peuvent être ajoutés dans ces fichiers : les lignes commençant par # sont ignorées.

La syntaxe de ces fichiers est volontairement simple, pour les rendre faciles à lire, à comprendre et à modifier.

Substitutions in debhelper config files
In compatibility level 13 and later, it is possible to use simple substitutions in some debhelper config files (particularly, the configuration files for dh_install(1)).

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

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

The following expansions are available:
DEB_HOST_*, DEB_BUILD_*, DEB_TARGET_*

Expands to the relevant dpkg-architecture(1) value (similar to dpkg-architecture -qVARIABLE_HERE).

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

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

Dollar

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

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

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

Newline, Space, Tab

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

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

env: NAME

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

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

Substitution limits

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

Fichiers de configuration de l’exécutable debhelper.
Si vous avez besoin de plus de flexibilité, de nombreux outils de debhelper (par exemple dh_install(1)) prennent en charge l’exécution d’un fichier de configuration comme un script.

Pour utiliser cette fonctionnalité, il suffit de marquer le fichier comme exécutable (<chmod +x debian/paquet.install >). L’outil essaiera de l’exécuter et utilisera la sortie du script. Le plus souvent, vous pouvez utiliser dh-exec(1) comme interpréteur du fichier de configuration pour conserver la majorité de la syntaxe originale tout en gagnant en flexibilité.

Lorsque vous utilisez des fichiers de configuration exécutables de debhelper, veuillez vous souvenir des choses suivantes :

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

Si vous avez besoin de construire le paquet sur un système de fichiers où l’on ne peut pas désactiver le bit d’exécution, vous pouvez utiliser dh-exec(1) et son script strip-output.

OPTIONS PARTAGÉES DE DEBHELPER

Tous les programmes de debhelper acceptent les options suivantes.
-v, --verbose

Mode verbeux : affiche toutes les commandes qui modifient le répertoire de construction du paquet.

--no-act

Empêche la construction de s’effectuer réellement. Si cette option est utilisée avec -v, le résultat sera l’affichage de ce que la commande aurait fait.

-a, --arch

Construit tous les paquets dépendants de l’architecture DEB_HOST_ARCH .

-i, --indep

Construit tous les paquets indépendants de l’architecture.

-ppaquet, --package=paquet

Construit le paquet nommé paquet. Cette option peut être répétée afin de faire agir debhelper sur plusieurs paquets.

-s, --same-arch

Alias obsolète pour -a.

Cette option est supprimée dans le niveau de compatibilité 12.

-Npaquet, --no-package=paquet

Exclut le paquet indiqué du processus de construction, même si l’option -a, -i ou -p l’impliquait.

--remaining-packages

Exclut du processus de construction les paquets qui ont déjà été construits préalablement par cette commande debhelper (c’est-à-dire, si la commande est présente dans le journal de debhelper du paquet). Par exemple, si vous avez besoin d’invoquer la commande avec des options spéciales seulement pour certains paquets binaires, utilisez cette option lors de la dernière invocation de la commande pour construire le reste des paquets avec les options par défaut.

-Ptmpdir, --tmpdir=tmpdir

Utilise le répertoire tmpdir pour construire les paquets. Sinon, par défaut, le répertoire utilisé est debian/paquet

--mainpackage=paquet

Cette option, peu utilisée, indique à debhelper le nom du « paquet principal » pour lequel les fichiers debian/toto peuvent être utilisés à la place des fichiers habituels debian/paquet.toto. Par défaut, debhelper considère que le « paquet principal » est le premier paquet énuméré dans le fichier debian/control.

-O=option|ensemble

Cette option est utilisée par dh(1) pour passer une ou plusieurs options, indiquées par l’utilisateur, à toutes les commandes exécutées. Si la commande prend en charge l’option ou l’ensemble d’options, elle prendra effet. Si la commande n’accepte pas l’option (ou une partie de l’ensemble d’options), elle sera ignorée.

OPTIONS COURANTES DE DEBHELPER

Certains programmes de debhelper acceptent les options ci-dessous. Consulter la page de manuel de chaque programme pour une explication complète du rôle de ces options.

-Xélément, --exclude=élément

Permet d’exclure un élément du traitement. Cette option peut être employée plusieurs fois afin d’exclure plusieurs éléments. L’élément est en général une partie du nom de fichier, et tous les fichiers contenant le texte indiqué seront exclus.

-A, --all

Précise que les fichiers (ou autres éléments) indiqués dans la ligne de commande concernent tous les paquets construits et pas seulement le premier.

OPTIONS DU PROCESSUS DE CONSTRUCTION

Les programmes debhelper dh_auto_* comportent plusieurs processus de construction et déterminent, de manière heuristique, lequel utiliser et comment. Il peut être utile de modifier ce comportement par défaut. Tous ces programmes dh_auto_* acceptent les options suivantes, typiquement passées à dh(1), qui les passe ensuite à tous les programmes dh_auto_*.
-Sprocessus de construction, --buildsystem=processus_de_construction

Oblige à utiliser le processus de construction indiqué au lieu de tenter de déterminer automatiquement celui qui pourrait être utilisable pour le paquet.

Pass none as buildsystem to disable auto-selection.

-Ddirectory, --sourcedir=directory, --sourcedirectory=directory

Considère que les sources du paquet sont situées dans le répertoire indiqué plutôt qu’au plus haut niveau de l’arborescence du paquet source.

-B[directory], --builddir[=directory], --builddirectory[=directory]

Permet de construire le paquet en dehors de la structure source en utilisant le répertoire indiqué comme répertoire de construction. Si le paramètre répertoire n’est pas indiqué, un répertoire de construction par défaut sera choisi.

Si cette option n’est pas indiquée, la construction se fera dans l’arborescence source à moins que le processus exige ou préfère le faire en dehors de cette structure. Dans ce cas, le répertoire par défaut sera utilisé même si --builddirectory n’est pas indiqué.

Même si le système préfère utiliser, pour la construction, un répertoire situé en dehors de l’arborescence source, il autorise quand même la construction dans l’arborescence source. Pour cela, il suffit d’utiliser un chemin d’accès au répertoire de construction identique au chemin d’accès au répertoire source.

--parallel, --no-parallel

Détermine si la construction parallèle doit être utilisée, si le système sous-jacent le permet. Le nombre de tâches parallèles est contrôlé, lors de la construction, par la variable d’environnement DEB_BUILD_OPTIONS ("Charte Debian," section 4.9.1). Ce nombre peut également être soumis aux limites spécifiques du système de construction.

Si aucune de ces options n’est précisée, debhelper active la parallélisation par défaut (--parallel) dans le niveau de compatibilité 10 (ou supérieur), et la désactive (--no-parallel) dans les autres niveaux.

Pour des raisons d’optimisation, dh essaiera de ne pas passer ces options aux processus fils si elles ne sont pas nécessaires et qu’elles sont les seules options. Cela arrive en particulier lorsque DEB_BUILD_OPTIONS n’a pas de paramètre parallel (ou si sa valeur est 1).

--max-parallel=maximum

Cette option implique --parallel et permet de limiter le nombre de tâches qui pourront être lancées lors d’une compilation parallèle. Si la construction du paquet est connue pour ne fonctionner qu’avec un certain niveau de parallélisme, il est possible de le régler à la valeur maximale censée fonctionner, ou que vous souhaitez mettre en œuvre.

En particulier, régler le maximum à 1 équivaut à l’utilisation de --no-parallel.

--reload-all-buildenv-variables

By default, dh(1) will compute several environment (e.g. by using dpkg-buildflags(1)) and cache them to avoid having all dh_auto_* tool recompute them.

When passing this option, the concrete dh_auto_* tool will ignore the cache from dh(1) and retrigger a rebuild of these variables. This is useful in the very rare case where the package need to do multiple builds but with different ...FLAGS options. A concrete example would be needing to change the -O parameter in CFLAGS in the second build:

    export DEB_CFLAGS_MAINT_APPEND=-O3
    %:
        dh $@
    override_dh_auto_configure:
        dh_auto_configure -Bbuild-deb ...
        DEB_CFLAGS_MAINT_APPEND=-Os dh_auto_configure \
           --reload-all-buildenv-variables -Bbuild-udeb ...

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

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

--list, -l

Liste tous les processus de construction pris en charge par le système. Cette liste inclut à la fois les processus par défaut et les processus tiers (marqués comme tels). Cette option montre également le processus de construction automatiquement sélectionné ou celui indiqué manuellement avec l’option --buildsystem.

NIVEAUX DE COMPATIBILITÉ

Parfois, des modifications majeures de debhelper doivent être faites et vont briser la compatibilité ascendante. Ces modifications sont nécessaires pour conserver à debhelper ses qualités de conception et d’écriture, car les besoins changent et le savoir-faire de l’auteur s’améliore. Pour éviter que de tels changements ne cassent les paquets existants, un concept de niveau de compatibilité debhelper a été introduit. On devra préciser à debhelper le niveau de compatibilité qu’il doit employer, ce qui modifiera son comportement de diverses manières.

Dans la version actuelle de debhelper, vous pouvez spécifier le niveau de compatibilité à utiliser dans debian/control en ajoutant une dépendance de construction (Build-Depends) sur le paquet debhelper-compat. Par exemple, pour exploiter la version 13, assurez-vous d’indiquer dans debian/control :

  Build-Depends: debhelper-compat (= 13)

Cela sert aussi à avoir une dépendance de construction sur une version suffisante de debhelper. Ainsi il n’est pas nécessaire d’indiquer une dépendance de construction particulière sur debhelper, sauf si vous avez besoin d’une mise à jour spécifique (comme pour l’introduction d’une nouvelle fonctionnalité ou une correction de bogue à l’intérieur d’un niveau de compatibilité).

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

  Build-Depends: debhelper (>= 13~)

Sauf indication contraire, toute la documentation de debhelper suppose l’utilisation du niveau de compatibilité le plus récent, et, dans la plupart des cas ne précise pas si le comportement est différent avec les niveaux de compatibilité antérieurs. De ce fait, si le niveau de compatibilité le plus récent n’est pas celui utilisé, il est fortement conseillé de lire les indications ci-dessous qui exposent les différences dans les niveaux de compatibilité antérieurs.

Niveaux de compatibilité pris en charge
Les niveaux de compatibilité sont les suivants :

Si vous mettez à jour depuis un niveau de compatibilité antérieur, veuillez consulter debhelper-obsolete-compat(7).

Ce mode est déconseillé.

-

Ce mode est déconseillé.

-

Ce mode est déconseillé.

-

Ce mode est déconseillé.

-

(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é)

Ce mode est déconseillé.

-

Retroactively applied to earlier compat levels: dh no longer accepts any of these since debhelper/12.4.

Les principales conséquences de cela sont :

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.

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

The compat 11 is discouraged for new packages as it suffers from feature interaction between dh_installinit and dh_installsystemd causing services to not run correctly in some cases. Please consider using compatibility mode 10 or 12 instead. More details about the issue are available in Debian#887904 and <https://lists.debian.org/debian-release/2019/04/msg01442.html>;.

Les changements par rapport à la version 10 sont :

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

La grande majorité des paquets ne seront pas affectés par ce changement.

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.

Note de migration : un bogue dans debhelper 11 jusqu’à 11.1.5 faisait que dh_installinfo ignorait --sourcedir de manière incorrecte.

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.

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.

Ce changement peut forcer les outils à traiter plus de fichiers qu’avant.

-

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

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.

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.

C’est la version dont l’usage est recommandé.

Les changements par rapport à la version 12 sont :

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

    # Disable dh_missing
    override_dh_missing:

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

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

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

    dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...

REMARQUES

Prise en charge de plusieurs paquets binaires
Si le paquet source produit plus d’un paquet binaire, les programmes de debhelper construiront tous les paquets binaires. Si le paquet source doit construire un paquet dépendant de l’architecture et un paquet indépendant de l’architecture, ce comportement ne conviendra pas. En effet, il convient de construire les paquets dépendants de l’architecture dans « binary-arch » de debian/rules, et les paquets indépendants de l’architecture dans « binary-indep ».

Pour résoudre ce problème, et pour un meilleur contrôle sur la construction des paquets par debhelper, tous les programmes de debhelper acceptent les options -a, -i, -p et -s. Ces options sont cumulatives. Si aucune n’est précisée, les programmes de debhelper construisent tous les paquets énumérés dans le fichier de contrôle, avec les exceptions ci-dessous.

Tout d’abord, chaque paquet dont le champ Architecture de debian/control ne contient pas l’architecture DEB_HOST_ARCH sera exclu ("Charte Debian," section 5.6.8).

De plus, quelques autres paquets peuvent être exclus suivant le contenu de la variable d’environnement DEB_BUILD_PROFILES et les champs Build-Profiles des paragraphes debian/control dans les paquets binaires, conformément au brouillon de la charte (voir <https://wiki.debian.org/BuildProfileSpec>;).

Interaction entre les sélections de paquets et les Build-Profiles

Les profils de construction (« Build-Profiles ») ont un effet sur le choix des paquets inclus dans les mécanismes de sélection de paquets de debhelper. Généralement, les sélections partent du principe que tous les paquets sont activés. Cette section décrit comment les sélections fonctionnent lorsqu’un paquet est désactivé par un profil de construction (ou par son absence).
-a/--arch, -i/--indep ou aucune option de sélection (un simple appel
« dh_X »)

Le paquet désactivé par le profil est silencieusement exclu de la sélection.

Veuillez noter que vous recevrez un avertissement si tous les paquets relatifs à cette sélection sont désactivés. Dans ce cas, il est généralement d’aucune utilité de construire.

-N paquet / --no-package paquet

Cette option est acceptée et ne fait rien.

-p paquet / --package paquet

Cette option est acceptée, mais debhelper n’agira pas sur le paquet.

Veuillez noter que cela n’a pas d’importance que le paquet soit activé ou désactivé par défaut.

Génération automatique des scripts Debian d’installation
Certaines commandes de debhelper produisent automatiquement des lignes de code de maintenance du paquet. Pour les inclure dans vos propres scripts de maintenance du paquet, il convient d’ajouter #DEBHELPER# à l’endroit où les lignes de code générées devront être insérées. #DEBHELPER# sera remplacé, par les lignes de code générées automatiquement, lors de l’exécution de dh_installdeb.

Si un script de maintenance n’existe pas et que debhelper doit y inclure quelque chose, alors debhelper créera le script de maintenance complètement.

Toutes les commandes de debhelper qui produisent automatiquement des lignes de code de cette façon peuvent inhiber cette production grâce à l’option -n (voir ci-dessus).

Nota : Les lignes de code insérées seront écrites dans le langage de l’interpréteur de commandes (shell). De ce fait, il est impossible de les placer directement dans un script Perl. Pour les insérer dans un script Perl, voici une solution (s’assurer que $1, $2, etc., sont bien définis par la commande set) :

  my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
  #DEBHELPER#
  EOF
  if (system($temp)) {
     my $exit_code = ($? >> 8) & 0xff;
     my $signal = $? & 0x7f;
     if ($exit_code) {
         die("Le script debhelper a échoué avec le code d'erreur : ${exit_code}");
     } else {
         die("Le script debhelper a été tué par le signal : ${signal}");
     }
  }

Génération automatique des diverses dépendances.
Certaines commandes de debhelper peuvent nécessiter des dépendances entre le paquet construit et d’autres paquets. Par exemple, si dh_installdebconf(1) est employé, le paquet devra dépendre de debconf. Si dh_installxfonts(1) est employé, le paquet deviendra dépendant d’une version particulière de xutils. Maintenir ces dépendances induites peut être pénible puisqu’elles découlent de la façon dont debhelper travaille. C’est pourquoi debhelper offre une solution d’automatisation.

Toutes les commandes de ce type, outre qu’elles documentent, dans leur page de manuel, les dépendances qu’elle induisent, généreront automatiquement une variable de substitution nommée ${misc:depends}. Si cette variable est exploitée dans le dossier debian/control, il sera automatiquement enrichi des dépendances induites par debhelper.

Ce processus est entièrement indépendant de ${shlibs:Depends} standard, produite par dh_makeshlibs(1), et de ${perl:Depends} produite par dh_perl(1). Il est également possible de choisir de ne pas les utiliser si les conjectures de debhelper ne correspondent pas à la réalité.

Répertoires de construction du paquet
Par défaut, tous les programmes de debhelper supposent que le répertoire temporaire utilisé pour construire l’arborescence des fichiers d’un paquet est debian/paquet.

Parfois, il peut être souhaitable d’utiliser un autre répertoire temporaire. C’est obtenu grâce à l’attribut -P. Par exemple, dh_installdocs -Pdebian/tmp utilisera debian/tmp comme répertoire temporaire. Nota : L’usage de -P implique que les programmes de debhelper ne construisent qu’un seul paquet à la fois. De ce fait, si le paquet source génère plusieurs paquets binaires, il faudra employer également le paramètre -p pour préciser l’unique paquet binaire à construire.

udebs
Debhelper prend en charge la construction des udebs. Pour créer un udeb avec debhelper, il faut ajouter « Package-Type: udeb » aux lignes de paquet dans debian/control. Debhelper essayera de construire des udebs, conformément aux règles de l’installateur Debian, en suffixant les fichiers de paquets générés avec .udeb, en n’installant aucune documentation dans un udeb, en omettant les scripts preinst, postrm, prerm et config, etc.

VARIABLES D’ENVIRONNEMENT

Les variables d’environnement suivantes peuvent influencer le comportement de debhelper. Il est important de noter que celles-ci doivent être des variables existantes pour que cela fonctionne correctement (pas simplement des variables de Makefile). Pour les définir proprement dans le fichier debian/rules, assurez vous de les exporter (« export »). Par exemple « export  DH_VERBOSE  ».
DH_VERBOSE

Mettre cette variable à 1 valide le mode verbeux. Debhelper affichera chaque commande exécutée. Valide aussi les journaux de construction bavards pour certains systèmes de construction comme autoconf.

DH_QUIET

Mettre cette variable à 1 valide le mode silencieux. Debhelper n’affichera aucune commande appelant le système de construction amont, et dh n’affichera aucune des sous-commandes appelées. En fonction du système de construction amont, cela pourra le rendre encore plus silencieux. Cela facilite la détection des messages importants, mais rend la sortie inutile en tant que journal de construction. Cette valeur est ignorée si DH_VERBOSE est aussi positionnée.

DH_COMPAT

Indique temporairement le niveau de compatibilité avec lequel debhelper doit fonctionner. Cette valeur supplante toute valeur précisée par Build-Depends sur debhelper-compat ou dans debian/compat.

DH_NO_ACT

Mettre cette variable à 1 pour activer le mode simulation (no-act).

DH_OPTIONS

All debhelper tools will parse command line arguments listed in this variable before any command option (as if they had been prepended to the command line arguments). Unfortunately, some third-party provided tools may not support this variable and will ignore these command line arguments.

En utilisant dh(1), des options peuvent être passées à chaque commande debhelper, ce qui est généralement mieux que d’utiliser DH_OPTIONS .

DH_ALWAYS_EXCLUDE

Si cette variable possède une valeur, elle sera ajoutée à l’option -X de toutes les commandes qui admettent cette option. De plus, dh_builddeb fera un rm -rf pour chaque chose correspondant à la valeur dans l’arbre de construction de paquet.

Cela peut être utile pour construire un paquet à partir d’une arborescence CVS. Dans ce cas, le réglage de DH_ALWAYS_EXCLUDE=CVS empêchera les répertoires CVS d’interférer subrepticement dans le paquet en construction. Ou, si un paquet possède une source compressée, (maladroitement) présente dans un répertoire CVS, il peut être utile d’exporter DH_ALWAYS_EXCLUDE=CVS dans debian/rules, pour que cette variable soit prise en compte quel que soit l’endroit où le paquet est construit.

Des exclusions multiples peuvent être séparées avec des caractères deux points, comme dans DH_ALWAYS_EXCLUDE=CVS:.svn.

DH_EXTRA_ADDONS

Les rajouts à dh indiqués seront exécutés lors de la séquence de commandes. Cela équivaut à les indiquer avec le drapeau --with dans le fichier debian/rules. Les rajouts précédés de --without ne seront pas exécutés, même s’ils sont indiqués dans cette variable d’environnement.

Cela est prévu pour être utilisé par les dérivées ou les configurations locales spécifiques qui ont besoin d’un rajout lors de plusieurs construction, sans avoir à modifier un grand nombre de fichier rules. Il est préférable d’éviter cette méthode et d’utiliser plutôt les drapeaux --with dans le fichier rules.

DH_COLORS , DPKG_COLORS

These variables can be used to control whether debhelper commands should use colors in their textual output. Can be set to "always", "auto" (the default), or "never".

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

NO_COLOR

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

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

CFLAGS , CPPFLAGS , CXXFLAGS , OBJCFLAGS , OBJCXXFLAGS , GCJFLAGS , FFLAGS ,
FCFLAGS , LDFLAGS

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

HOME , XDG_*

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

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

VOIR AUSSI

/usr/share/doc/debhelper/examples/

Un ensemble d’exemples de fichiers debian/rules qui utilisent debhelper.

<http://joeyh.name/code/debhelper/>;

Le site internet de debhelper.

AUTEUR

Joey Hess <joeyh [AT] debian.org>

TRADUCTION

Cette traduction est maintenue à l’aide de l’outil po4a <URL:http://po4a.alioth.debian.org/>; par l’équipe francophone de traduction de Debian.

Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french [AT] lists.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> ».