debhelper.de

title: debhelper.de(7)

summary: die Debhelper\-Werkzeugsammlung

text:
# debhelper.de(7)

## NAME
debhelper - die Debhelper-Werkzeugsammlung

## ÜBERSICHT
dh_* [-v] [-a] [-i] [--no-act] [-pPaket] [-NPaket] [-Ptemporäres_Verzeichnis]

## BESCHREIBUNG
Debhelper ist dafür da, Ihnen beim Bau eines Debian-Pakets zu helfen. Die Philosophie hinter Debhelper ist, eine kleine, einfach und leicht verständliche Werkzeugsammlung bereitzustellen, die in debian/rules verwandt wird, um verschiedene geläufige Aspekte der Paketerstellung zu automatisieren und Ihnen auf diese Weise Arbeit abzunehmen. Darüber hinaus können diese Werkzeuge bis zu einem gewissen Grad an etwaige Änderungen an der Debian-Richtlinie angepasst werden, sodass die Pakete, welche die Werkzeuge verwenden, lediglich neu erzeugt werden müssen, um der geänderten Richtlinie zu entsprechen.

Eine typische debian/rules-Datei, die Debhelper benutzt, ruft mehrere Debhelper-Befehle hintereinander auf oder verwendet dh(1), um diesen Prozess zu automatisieren. Beispiele für Regeldateien, die Debhelper einsetzen, liegen in /usr/share/doc/debhelper/examples/.

Um ein neues Debian-Paket unter Benutzung von Debhelper zu erstellen, können Sie einfach eine Beispielregeldatei kopieren und manuell bearbeiten. Oder Sie probieren das Paket dh-make aus; dieses enthält einen dh_make-Befehl, welcher den Prozess teilweise automatisiert. Für eine behutsamere Einführung enthält das Paket ucmaint-guide ein Lernprogramm, mit dem Sie Ihr erstes Paket unter mit Hilfe von Debhelper erstellen.

Except where the tool explicitly denotes otherwise, all of the debhelper tools assume that they run from the root directory of an unpacked source package. This is so they can locate files like debian/control when needed.

## DEBHELPER-BEFEHLE
Hier ist die Liste der Debhelper-Befehle, die Sie benutzen können. Zusätzliche Dokumentation finden Sie in deren Handbuchseiten.

dh_auto_build(1)

baut ein Paket automatisch

dh_auto_clean(1)

räumt nach dem Bauen automatisch auf

dh_auto_configure(1)

konfiguriert das Paket automatisch vor dem Bauen.

dh_auto_install(1)

führt »make install« oder Ähnliches aus

dh_auto_test(1)

führt automatisch die Test-Suites eines Pakets aus

dh_bugfiles(1)

installiert Dateien zur Anpassung von Fehlerberichten in Bauverzeichnisse von Paketen.

dh_builddeb(1)

baut binäre Debian-Pakete

dh_clean(1)

räumt die Bauverzeichnisse des Pakets auf

dh_compress(1)

komprimiert Dateien und korrigiert symbolische Links in Bauverzeichnissen von Paketen

dh_dwz(1)

optimiert DWARF-Fehlersuchinformationen in ELF-Binärdateien über dwz

dh_fixperms(1)

korrigiert Zugriffsrechte von Dateien in Bauverzeichnissen

dh_gencontrol(1)

erzeugt und installiert die Steuerdatei »control«

dh_icons(1)

aktualisiert die Zwischenspeicher von Freedesktop-Symbolen

dh_install(1)

installiert Dateien in Bauverzeichnisse von Paketen

dh_installcatalogs(1)

installiert und registriert SGML-Kataloge

dh_installchangelogs(1)

installiert Changelogs in die Paketbauverzeichnisse

dh_installcron(1)

installiert Cron-Skripte in etc/cron.*

dh_installdeb(1)

installiert Dateien in das Verzeichnis DEBIAN.

dh_installdebconf(1)

installiert Dateien, die von Debconf im Paketbauverzeichnis benutzt werden

dh_installdirs(1)

erstellt Unterverzeichnisse in den Paketbauverzeichnissen

dh_installdocs(1)

installiert Dokumentation in Paketbauverzeichnisse

dh_installemacsen(1)

registriert ein Emacs-Erweiterungspaket

dh_installexamples(1)

installiert Beispieldateien in die Paketbauverzeichnisse.

dh_installifupdown(1)

installiert »if-up«- und »if-down«-Hooks.

dh_installinfo(1)

installiert Info-Dateien

dh_installinit(1)

installiert Dienstinitialisierungsdateien in Paketbauverzeichnisse

dh_installinitramfs(1)

installiert Initramfs-Hooks und richtet Maintscripts ein

dh_installlogcheck(1)

installiert Regeldateien zur Protokollprüfung in etc/logcheck/

dh_installlogrotate(1)

installiert Konfigurationsdateien von Logrotate

dh_installman(1)

installiert Handbuchseiten in Paketbauverzeichnisse

dh_installmenu(1)

installiert Debian-Menü-Dateien in Paketbauverzeichnisse

dh_installmime(1)

installiert MIME-Dateien in Paketbauverzeichnisse

dh_installmodules(1)

registriert Kernel-Module

dh_installpam(1)

installiert PAM-Unterstützungsdateien

dh_installppp(1)

installiert PPP-ip-up- und -ip-down-Dateien

dh_installudev(1)

installiert udev-Regeldateien

dh_installwm(1)

registriert einen Fenstermanager

dh_installxfonts(1)

registriert X-Schriften

dh_link(1)

erzeugt symbolische Links in Paketbauverzeichnisse

dh_lintian(1)

installiert Override-Dateien für Lintian in Paketbauverzeichnisse

dh_listpackages(1)

listet Binärpakete auf, auf die Dephelper einwirken wird

dh_makeshlibs(1)

erstellt automatisch die Shlibs-Datei und ruft dpkg-gensymbols auf

dh_md5sums(1)

erzeugt die Datei DEBIAN/md5sums

dh_movefiles(1)

verschiebt Dateien aus debian/tmp in Unterpakete

dh_perl(1)

berechnet Perl-Abhängigkeiten und räumt nach MakeMaker auf

dh_prep(1)

führt Säuberungsaktionen als Vorbereitung des Baus von Binärpaketen durch

dh_shlibdeps(1)

berechnet Abhängigkeiten gemeinsam benutzter Bibliotheken

dh_strip(1)

entfernt Symbole aus Programmen, gemeinsam benutzten Bibliotheken und einigen statischen Bibliotheken

dh_systemd_enable(1)

aktiviert/deaktiviert Systemd-Unit-Dateien

dh_systemd_start(1)

Start/Stopp/Neustart von Systemd-Unit-Dateien

dh_testdir(1)

Verzeichnis vor dem Bauen des Debian-Pakets testen

dh_testroot(1)

stellt sicher, dass ein Paket mit dem notwendigen Umfang an Root-Rechten gebaut wird.

dh_usrlocal(1)

migriert usr/local-Verzeichnisse zu Betreuerskripten

### Veraltete Befehle
Ein paar Debhelper-Befehle sind veraltet und sollten nicht benutzt werden.

dh_installmanpages(1)

Handbuchseiteninstallationsprogramm im alten Stil (veraltet)

### Weitere Befehle
Falls ein Programmname mit dh_ beginnt und das Programm nicht auf obiger Liste steht, dann ist es nicht Teil des Debhelper-Pakets, sollte aber trotzdem wie die anderen auf dieser Seite beschriebenen Programme funktionieren.

## DEBHELPER-KONFIGURATIONSDATEIEN
Viele Debhelper-Befehle machen von den Dateien in debian/ Gebrauch, um zu steuern, was sie tun. Neben den üblichen debian/changelog und debian/control, die in allen Paketen enthalten sind (nicht nur in denen, die Debhelper benutzen), können einige zusätzliche Dateien verwandt werden, um das Verhalten bestimmter Debhelper-Befehle zu konfigurieren. Diese Dateien heißen üblicherweise debian/Paket.foo (wobei Paket natürlich durch das Paket ersetzt wird, auf das es sich auswirkt).

dh_installdocs benutzt beispielsweise Dateien mit dem Namen debian/package.docs, um die Dokumentationsdateien aufzulisten, die es installieren wird. Welche Dateien die einzelnen Befehle heranziehen, ihre Namen und Formate, entnehmen Sie den entsprechenden Handbuchseiten. Im Allgemeinen sind diese Dateien Listen von Dateien, die bearbeitet werden, eine Datei pro Zeile. Einige Programme in Debhelper bedienen sich Paaren von Dateien und Zielen oder etwas kompliziertere Formate.

Beachten Sie, das debhelper debian/foo verwenden wird, wenn nur ein Binärpaket in debian/control aufgeführt ist und es keine Datei debian/package.foo gibt. In Kompatibilitätsstufen vor 15 geschieht dies auch für das erste in debian/control aufgeführte Binärpaket, falls es mehrere Binärpakete gibt. Oft ist es jedoch eine gute Idee, das Präfix Paket. zu behalten, da es eindeutiger ist und beim Upgrade auf Kompatibilitätsstufe 15 sowieso benötigt wird.

Außerdem gibt es einige spezielle Fälle, in denen Debhelper immer auf eine präfix-lose Version zurückfällt. Das sind Fälle wie debian/copyright und debian/changelog, in denen die Dateien generell für alle Binärpakete verwendet werden und notwendig sind.

In einigen seltenen Fällen möchten Sie möglicherweise unterschiedliche Versionen dieser Dateien für unterschiedliche Architekturen oder Betriebssysteme haben. Falls Dateien mit den Namen debian/Paket.foo.ARCHITEKTUR oder debian/Paket.foo.BETRIEBSSYSTEM existieren, wobei ARCHITEKTUR und BETRIEBSSYSTEM der Ausgabe von »dpkg-architecture -qDEB_HOST_ARCH_OS« entsprechen, dann werden sie gegenüber anderen, allgemeineren Dateien, bevorzugt.

Meist werden diese Konfigurationsdateien benutzt, um verschiedene Typen von Dateien anzugeben – zu installierende Dokumentations- oder Beispieldateien, Dateien zum Verschieben und so weiter. Wenn es in Fällen wie diesem zweckmäßig ist, können Sie die Standardplatzhalterzeichen der Shell in den Dateien verwenden (?, * und [..]-Zeichenklassen). Sie können außerdem Kommentare in diese Dateien einfügen; Zeilen, die mit # beginnen, werden ignoriert.

Die Syntax dieser Dateien ist absichtlich sehr einfach gehalten, um sie leicht lesbar, verständlich und änderbar zu machen.

### Ersetzungen in Debhelper-Konfigurationsdateien
In Kompatibilitätsstufe 13 und neuer ist es möglich, in den debhelper-Konfigurationsdateien einfache Ersetzungen für die folgenden Werkzeuge zu verwenden:

- dh_clean

- dh_install

- dh_installcatalogs

- dh_installdeb

- dh_installdirs

- dh_installdocs

- dh_installexamples

- dh_installinfo

- dh_installman

- dh_installvm

- dh_link

- dh_missing

- dh_ucf

Alle Ersetzungsvariablen haben die Form ${foo} und die Klammern sind Pflicht. Variablennamen berücksichtigen Groß- und Kleinschreibung und bestehen aus alphanumerischen Zeichen (a-zA-Z0-9), Bindestrichen (-), Unterstrichen (_) sowie Doppelpunkten (:). Das erst Zeichen muss alphanumerisch sein.

Falls Sie ein Dollarzeichen benötigen, das kein Ersetzen auslösen kann, können Sie entweder die ${Dollar}-Ersetzung oder die Sequenz ${} verwenden.

Die folgenden Expandierungen sind verfügbar:

DEB_HOST_*, DEB_BUILD_*, DEB_TARGET_*

expandiert auf den passenden dpkg-architecture(1)-Wert (ähnlich dpkg-architecture -qVARIABLE_HIER). Im Zweifelsfall ist die Variante DEB_HOST_* diejenige, die sowohl für natives Bauen als auch für andere Architekturen funktioniert.

Aus Leistungsgründen versucht Debhelper, diese Namen aus der Umgebung aufzulösen, bevor es Rat bei dpkg-architecture(1) sucht. Dies sei hauptsächlich der Vollständigkeit halber erwähnt und hat in den meisten Fällen keine Bedeutung.

Dollar

expandiert auf ein einzelnes $-Symbol. Dieses Symbol wird niemals als Teil der Ersetzungsvariable angesehen. Dies bedeutet:

```
   # löst einen Fehler aus
   ${KEINE_DERARTIGE_MARKIERUNG}
   # expandiert auf den genauen Wert »${KEINE_DERARTIGE_MARKIERUNG}«
   ${Dollar}{KEINE_DERARTIGE_MARKIERUNG}

```

Diese Variable entspricht der Sequenz ${} und beides kann synonym benutzt werden.

Newline, Space, Tab

expandiert auf einen einzelnen ASCII-Zeilenumbruch, Leerzeichen beziehungsweise Tabulator. Dies kann nützlich sein, wenn Sie ein Leerraumzeichen (z.B. Leerzeichen) einfügen möchten, wo es andernfalls entfernt oder als Trennzeichen benutzt würde.

env:NAME

expandiert zur Umgebungsvariable NAME. Die Umgebungsvariable muss gesetzt sein (eine leere Zeichenkette reicht).

Beachten Sie, dass alle Variablen auf einen definierten Wert expandiert werden müssen. Wenn Debhelper beispielsweise ${env:FOO} sieht, wird es darauf bestehen, dass die Umgebungsvariable FOO gesetzt ist (eine leere Zeichenkette reicht).

Ersetzungsbeschränkungen

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

Note the limit is per token. Every helper decides its own definition of a token. The common case of files like debian/package.install, each token is a file/path name.

Ersetzungsbeschränkungen: Filterung

Die eingebaute Ersetzung kann nicht dazu verwendet werden, Inhalte zu »filtern«. Versuche, »Kommentare« oder »Leerzeilen« mittels Ersetzungen zu erzeugen hat als Ergebnis, dass diese Variablen selbst als Markierung innerhalb des gegebenen Inhalts interpretiert werden.

Falls Sie filtern wollen erwägen Sie die Verwendung einer ausführbaren Debhelper-Konfigurationsdatei mit dh-exec als Interpreter. Das Werkzeug dh-exec unterstützt zahlreiche Funktionalitäten standardmäßig. Denken Sie aber daran, dass dh-exec seine eigene Logik für Ersetzungen hat, die mit den Funktionalitäten von Debhelper interagieren kann.

### Ausführbare Debhelper-Konfigurationsdateien
Falls Sie zusätzliche Flexibilität benötigen, unterstützen viele Debhelper-Werkzeuge (z.B. dh_install(1)) die Ausführung einer Konfigurationsdatei als Skript.

Um diese Funktionalität zu nutzen, markieren Sie die Konfigurationsdatei einfach als ausführbar (z.B. chmod +x debian/Paket.install) und das Werkzeug wird versuchen, es auszuführen und die Ausgabe des Skripts zu verwenden. In vielen Fällen können Sie auch dh-exec(1) als Interpreter der Konfigurationsdatei verwenden, um das Meiste der Originalsyntax beizubehalten, obwohl Sie die zusätzliche Flexibilität wie gewünscht erhalten.

Wenn Sie ausführbare Debhelper-Konfigurationsdateien verwenden, sollten Sie Folgendes wissen:

- Die ausführbare Konfigurationsdatei muss erfolgreich enden (d.h. der Rückgabewert sollte einen Erfolg anzeigen).

- Auf Kompatibilitätsstufen oberhalb von 13 unterliegt die Ausgabe Ersetzungen (siehe "Ersetzungen in Debhelper-Konfigurationsdateien"), soweit das Werkzeug diese unterstützt. Denken Sie daran, Vorsicht walten zu lassen, falls Ihr Generator auch Ersetzungen bereitstellt, da dies zu unnötiger Verwirrung führen kann. Im besonderen verfügt das üblicherweise verwendete Werkzeug dh-exec über eine eigene Unterstützung für Ersetzungen. Andernfalls wird die Ausgabe exakt so benutzt, wie sie ist. Insbesondere wird Debhelper Platzhalter nicht expandieren oder Kommentare und Leerraumzeichen aus der Ausgabe entfernen. Das Werkzeug dh-exec verfügt über ein Ausgangsfilter, das diese Dinge standardmäßig entfernt.

Falls Sie das Paket auf einem Dateisystem bauen, auf dem Sie das Ausführungsbit nicht deaktivieren können, können Sie dh-exec(1) und sein Skript strip-output verwenden.

## GEMEINSAM BENUTZTE DEBHELPER-OPTIONEN
Die folgenden Befehlszeilenoptionen werden von allen Debhelper-Programmen unterstützt.

-v, --verbose

Detailreicher Modus: zeigt Befehle, die das Paketbauverzeichnis ändern. Beachten Sie, dass der detailreiche Modus möglicherweise auch »interne« Befehle ausgibt, die das Paketbauverzeichnis nicht direkt betreffen.

--no-act

tut nicht wirklich etwas. Falls es zusammen mit -v benutzt wird, wird als Ergebnis ausgegeben, was der Befehl getan hätte.

-a, --arch

wirkt sich auf architekturabhängige Pakete aus, die für die Architektur DEB_HOST_ARCH gebaut werden sollen.

-i, --indep

wirkt sich auf alle architektur-unabhängigen Pakete aus.

-pPaket, --package=Paket

wirkt sich auf das Paket mit Namen Paket aus. Diese Option kann mehrfach angegeben werden, damit Debhelper mit einer Zusammenstellung von Paketen arbeitet.

-s, --same-arch

missbilligter Alias von -a. Die Option wurde in Kompatibilitätsstufe 12 entfernt.

-NPaket, --no-package=Paket

verhindert Auswirkungen auf das angegebene Paket, sogar wenn die Optionen -a, -i oder -p das Paket als ein zu verarbeitendes auflisten.

--remaining-packages

wirkt sich nicht auf die Pakete aus, die dieser Debhelper-Befehl bereits durchlaufen hat (d.h. falls der Befehl im Debhelper-Protokoll des Pakets auftaucht). Falls Sie zum Beispiel den Befehl nur bei einigen Binärpaketen mit speziellen Optionen aufrufen müssen, geben Sie diese Option beim letzten Aufruf des Befehls an, um die restlichen Pakete mit Standardeinstellungen zu verarbeiten.

-Ptemporäres_Verzeichnis, --tmpdir=temporäres_Verzeichnis

benutzt temporäres_Verzeichnis als Bauverzeichnis des Pakets. Voreinstellung ist debian/Paket.

--mainpackage=Paket

Veraltet: Diese Option hat für Kompatibilitätsstufe 15 und neuer keinen praktischen Nutzen, weil deren Auswirkung in Kompatibilitätsstufe 15 entfernt worden ist. Diese selten benutzte Option ändert das Paket, welches Paket Debhelper als »Hauptpaket« ansieht, sprich als das Paket, welches zuerst in debian/control aufgeführt wird und für das die debian/foo-Dateien anstelle der üblichen debian/Paket.foo-Dateien verwandt werden können.

-O=Option|Bündel

Dies wird von dh(1) verwandt, wenn benutzerdefinierte Optionen an alle von ihm ausgeführten Befehle weitergereicht werden. Falls der Befehl die angegebene Option oder das ganze Bündel von Optionen unterstützt, kommt er zum Tragen. Falls nicht, wird er ignoriert.

## HÄUFIGE DEBHELPER-OPTIONEN
Die folgende Befehlszeile wird von einigen Debhelper-Programmen unterstützt. Eine vollständige Erklärung, was jede Option tut, finden Sie in den Handbuchseiten jedes einzelnen Programms.

-n

verändert keine postinst-, postrm- etc. Skripte.

-XElement, --exclude=Element

schließt ein Element von der Verarbeitung aus. Diese Option kann mehrfach benutzt werden, um mehr als nur eins auszuschließen. Das <Element> ist üblicherweise Teil eines Dateinamens und jede Datei, die den angegebenen Text enthält, wird ausgeschlossen.

-A, --all

bewirkt, dass Dateien oder andere Elemente, die auf der Befehlszeile angegeben wurden, sich in ALLEN entsprechenden Paketen auswirken, nicht nur im ersten.

## BAUSYSTEMOPTIONEN
Die folgenden Befehlszeilenoptionen werden von allen dh_auto_*-Debhelper-Programmen unterstützt. Diese Programme unterstützen eine Vielzahl von Bausystemen und bestimmen normalerweise heuristisch, welches benutzt werden soll und wie es verwendet wird. Sie können diese Befehlszeilenoptionen nutzen, um das Standardverhalten zu ändern. Typischerweise werden sie an dh(1) übergeben, das sie dann an alle dh_auto_*-Programme übergibt.

-SBausystem, --buildsystem=Bausystem

erzwingt die Benutzung des angegebenen Bausystems, anstatt zu versuchen, automatisch eins auszuwählen, das für das Paket geeignet sein könnte. übergibt none als Bausystem, um automatisches Auswählen zu deaktivieren.

-DVerzeichnis, --sourcedir=Verzeichnis, --sourcedirectory=Verzeichnis

geht davon aus, dass der Quellverzeichnisbaum des Originalpakets im angegebenen Verzeichnis statt auf der obersten Verzeichnisebene des Debian-Quellpaketverzeichnisbaums liegt. Warnung: Für die --sourcedir-Variante gibt es aus historischen Gründen eine ähnlich benannte Option in dh_install und dh_missing (etc.). Obwohl ihre Namen identisch sind, dienen sie völlig unterschiedlichen Zwecken, somit können in einigen Fällen Fehler auftreten, wenn diese Variante an dh übergeben wird (und dieses sie seinerseits an alle anderen Werkzeuge weitergibt).

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

aktiviert das Bauen aus dem Quelltext und benutzt das angegebene Verzeichnis] als Bauverzeichnis. Falls der Parameter Verzeichnis] weggelassen wurde, wird ein Vorgabebauverzeichnis ausgewählt. Falls diese Option nicht angegeben ist, wird standardmäßig in der Quelle gebaut, falls das Bausystem nicht das Bauen außerhalb des Quellverzeichnisbaums erfordert oder bevorzugt. In einem solchen Fall wird das Standardbauverzeichnis benutzt, selbst wenn --builddirectory angegeben wurde.

Falls das Bausystem das Bauen außerhalb des Quellverzeichnisbaums bevorzugt, aber das Bauen innerhalb der Quelle immer noch erlaubt, kann Letzteres wieder aktiviert werden, indem ein Bauverzeichnispfad übergeben wird, der dem Quellverzeichnispfad entspricht.

--parallel, --no-parallel

prüft, ob parallel gebaut werden soll, falls das zugrundeliegende Bausystem dies unterstützt. Die Anzahl paralleler Aufgaben wird zur Bauzeit durch die Umgebungsvariable DEB_BUILD_OPTIONS ("Debian-Richtlinie, Abschnitt 4.9.1") gesteuert, Sie könnte außerdem Gegenstand einer bausystemspezifischen Begrenzung sein. Falls keine der Optionen angegeben wurde, ist die Voreinstellung von Debhelper derzeit --parallel in Kompatibilitätsversion 10 (oder höher) und andernfalls --no-parallel.

Zwecks Optimierung wird dh versuchen, die Übergabe dieser Optionen an Unterprozesse zu vermeiden, falls sie unnötig sind und als einzige Optionen übergeben werden. Dies geschieht insbesondere dann, wenn DEB_BUILD_OPTIONS keinen parallel-Parameter hat (oder dessen Wert 1 ist).

--max-parallel=Maximum

Diese Option impliziert --parallel und erlaubt die weitere Begrenzung der Anzahl von Aufgaben, die bei einem parallelen Bau benutzt werden können. Falls bekannt ist, dass das Bauen des Pakets nur mit einer bestimmten Stufe der Gleichzeitigkeit funktioniert, können Sie diese auf die höchste Stufe setzen, von der bekannt ist, dass sie funktioniert oder auf die, von der Sie wünschen, dass sie unterstützt wird. Übrigens bewirkt das Setzen des Maximums auf 1 dasselbe wie die Verwendung von --no-parallel.

--reload-all-buildenv-variables

Standardmäßig wird dh(1) mehrere Umgebungsvariablen berechnen (z.B. mittels dpkg-buildflags(1)) und sie zwischenspeichern, um zu verhindern, dass alle dh_auto_*-Werkzeuge sie erneut berechnen. Wenn diese Option übergeben wird, wird das konkrete dh_auto_*-Werkzeug den Zwischenspeicher von dh(1) ignorieren und das neue Erzeugen dieser Variablen auslösen. Dies hilft in den sehr seltenen Fällen, in denen das Paket mehrere Bauvorgänge mit unterschiedlichen …FLAGS-Optionen benötigt. Ein konkretes Beispiel wäre die Notwendigkeit, den Parameter -O in CFLAGS beim zweiten Bauen abzuändern:

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

```

Ohne --reload-all-buildenv-variables im zweiten Aufruf von dh_auto_configure(1) würde die Änderung in DEB_CFLAGS_MAINT_APPEND ignoriert werden, da dh_auto_configure(1) den von durch dh(1) zwischengespeicherten CFLAGS-Wert benutzen würde.

Diese Option ist mit debhelper (>= 12.7~) nur verfügbar, wenn das Paket Kompatibilitätsstufe 9 oder neuer verwendet.

--list, -l

listet alle Bausysteme auf, die auf diesem System von Debhelper unterstützt werden. Diese Liste enthält sowohl Standardbausysteme als auch Bausysteme Dritter (als solche gekennzeichnet). Außerdem zeigt es, welches Bausystem automatisch ausgewählt werden würde oder welches durch die Option --buildsystem manuell angegeben wird.

## KOMPATIBILITÄTSSTUFEN
Von Zeit zu Zeit müssen wesentliche, nicht rückwärtskompatible Änderungen an Debhelper vorgenommen werden, um es so sauber und übersichtlich wie möglich zu halten, denn die Bedürfnisse ändern sich bzw. sein Autor sammelt mehr Erfahrung. Um zu verhindern, dass solche wesentlichen Änderungen existierende Pakete beschädigen, ist das Konzept der Debhelper-Kompatibilitätsstufen eingeführt worden. Sie müssen Debhelper mitteilen, welche Kompatibilitätsstufe es nutzen soll und sie ändert sein Verhalten auf verschiedene Arten.

Im aktuellen Debhelper können Sie die Kompatibilitätsstufe in debian/control angeben, indem Sie ein Build-Depends für das Paket Debhelper-Compat hinzufügen. Um beispielsweise den Modus v13 zu benutzen, stellen Sie sicher, dass debian/control Folgendes enthält:

```
  Build-Depends: debhelper-compat (= 13)
```

Dies dient auch als eine geeignete versionierte Bauabhängigkeit zu einer ausreichenden Version des Debhelper-Pakets, so dass Sie keine separate versionierte Bauabhängigkeit zum Debhelper-Paket angeben müssen, es sei denn, Sie benötigen eine besondere Zwischenveröffentlichung von Debhelper (wie für die Veröffentlichung einer neuen Funktionalität oder einer Fehlerbehebung innerhalb einer Kompatibilitätsstufe).

Beachten Sie, dass Debhelper-Compat nicht für experimentelle oder Beta-Kompatibilitätsstufen vorgesehen ist. Pakete, die mit diesen Kompatibilitätsstufen experimentieren, sollten die Kompatibilitätsstufe in das Feld X-DH-Compat des Source-Abschnitts der Datei debian/control eintragen (oder, falls nur für bestimmte Befehle, in die Umgebungsvariable DH_COMPAT).

Frühere Versionen von Debhelper benötigten die Angabe der Kompatibilitätsstufe in der Datei debian/compat, und Debhelper bis zur Version 14 unterstützen dies zum Zweck der Rückwärtskompatibilität. Um diese Methode zu verwenden, sollte die Datei debian/compat die Kompatibilitätsstufe als einzelne Zahl enthalten und keinen weiteren Inhalt. Falls Sie die Kompatibilitätsstufe mit dieser Methode angeben, muss Ihr Paket auch eine passende versionierte Bauabhängigkeit auf das Paket Debhelper haben, und zwar mit einer Version, die identisch zu (oder höher als) die Kompatibilitätsstufe ist, die von ihrem Paket verwandt wird. Daher sollten Sie, falls Sie die Kompatibilitätsstufe 13 in debian/compat angeben, sicherstellen, dass debian/control Folgendes enthält:

```
  Build-Depends: debhelper (>= 13~)
```

Beachten Sie, dass Sie genau eine Methode verwenden müssen, um die standardmäßige Kompatibilitätsstufe eines Pakets anzugeben. Wo immer möglich, empfiehlt sich die Bauabhängigkeit auf Debhelper-Compat.

Falls nötig, kann die Umgebungsvariable DH_COMPAT dazu verwendet werden, die Kompatibilitätsstufe für einen bestimmten Befehl außer Kraft zu setzen. Diese Funktionalität eignet sich hauptsächlich für die vorübergehende Anhebung einiger Befehle auf eine neue Kompatibilitätsstufe oder zum selektiven Zurückhalten auf einer niedrigeren Stufe. Es sollte sparsam eingesetzt werden, weil es im Endeffekt zu Spezialfällen in der debian/rules-Datei führt, die für unangenehme Überraschungen für Betreuer und Prüfer sorgen können (oder auch langfristig bei Ihnen selbst).

Wenn nicht anders angegeben, geht sämtliche Debhelper-Dokumentation davon aus, dass Sie die aktuellste Kompatibilitätsstufe nutzen, und weist in den meisten Fällen nicht darauf hin, wenn sich dieses Verhalten von einer älteren Kompatibilitätsstufe unterscheidet. Sollten Sie also nicht die aktuellste Kompatibilitätsstufe benutzen, ist es eine gute Idee, folgende Hinweise zu den Unterschieden gegenüber älteren Kompatibilitätsstufen zu lesen.

### Unterstützte Kompatibilitätsstufen
Die Liste unterstützter Kompatibilitätsstufen und die entsprechende Upgrade-Prüfliste sind nach debhelper-compat-upgrade-checklist(7) verschoben worden.

## ANMERKUNGEN

### Unterstützung mehrerer Binärpakete
Falls Ihr Quellpaket mehr als ein Binärpaket erzeugt, werden die Debhelper-Programme standardmäßig auf alle Paketen einwirken. Falls es vorkommt, dass Ihr Quellpaket ein architekturabhängiges Paket und ein anderes architekturunabhängiges Paket erzeugt, ist dies nicht das korrekte Verhalten, da Sie die architekturabhängigen Pakete im debian/rules-Ziel »binary-arch« erzeugen müssen und die unabhängigen Pakete im debian/rules-Ziel »binary-indep«.

Um dies zu erleichtern sowie Ihnen mehr Kontrolle darüber zu geben, auf welche Pakete Debhelper-Programme einwirken, akzeptieren alle Debhelper-Programme die Parameter -a, -i, -p und -s. Diese Parameter sind kumulativ. Falls keiner angegeben wurde, wirken Debhelper-Programme standardmäßig auf alle Paketen ein, die in der Datei »control« aufgeführt sind, mit nachfolgenden Ausnahmen.

Zuerst werden alle Pakete, deren Architecture-Feld in debian/control nicht mit der DEB_HOST_ARCH-Architektur übereinstimmt, ausgeschlossen ("Debian Policy, Abschnitt 5.6.8").

Außerdem können einige zusätzliche Paket basierend auf dem Inhalt der Umgebungsvariable DEB_BUILD_PROFILES und den Feldern Build-Profiles in den Abschnitten für binäre Pakete in debian/control ausgeschlossen werden. Dies geschieht gemäß der Entwurfrichtlinie unter <https://wiki.debian.org/BuildProfileSpec>.

Zusammenspiel zwischen Paketauswahl und Bauprofilen

Bauprofile beeinflussen, welche Pakete im Paketauswahlmechanismus von Debhelper enthalten sind. Im Allgemeinen wird die Paketauswahl unter der Annahme beschrieben, dass alle Pakete aktiviert sind. Dieser Abschnitt beschreibt, wie die Auswahl reagiert, wenn ein Paket aufgrund des aktiven Bauprofils (oder das Fehlen des aktiven Bauprofils) deaktiviert wird.

-a/--arch, -i/--indep ODER keine Auswahloptionen (ein roher »dh_X«-Aufruf)

Das durch Bauprofile deaktivierte Paket wird stillschweigend aus der Auswahl ausgeschlossen. Beachten Sie, dass Sie eine Warnung bekommen, falls alle zu dieser Auswahl gehörenden Pakete deaktiviert werden. In diesem Fall ist der Bau im Allgemeinen überhaupt sinnlos.

-N Paket / --no-package Paket

Die Option wird akzeptiert und hat keine Wirkung.

-p Paket / --package Paket

Die Option wird akzeptiert, aber Debhelper wird nichts an dem Paket ändern.

Beachten Sie, dass es keine Rolle spielt, ob das Paket standardmäßig aktiviert oder deaktiviert ist.

### Automatisches Erzeugen von Debian-Installationsskripten
Einige Debhelper-Befehle werden automatisch Teile der Debian-Betreuerskripte erzeugen. Falls Sie diese automatisch erzeugten Dinge in Ihre existierenden Debian-Betreuerskripte einfügen möchten, dann müssen Sie Ihren Skripten #DEBHELPER# an der Stelle platzieren, an die der Kode hinzugefügt werden soll. #DEBHELPER# wird bei der Ausführung durch beliebigen automatisch erzeugten Kode ersetzt, wenn Sie dh_installdeb ausführen.

Falls ein Skript noch gar nicht existiert und Debhelper etwas darin hinzufügen muss, dann wird Debhelper das komplette Skript erstellen.

When inserting the #DEBHELPER# token into a script, consider whether any of the hand written code has a compelling reason to appear before the #DEBHELPER# token. The #DEBHELPER# token will generally contain the code that start (postinst) or stop (prerm/preinst) any services the package is providing. Often (but not always), it is better to let the code from #DEBHELPER# run first. Common exceptions include things like set -e, initializing debconf (when needed) and special-cases like generation or hand-written management of configuration files. These things should generally occur before the #DEBHELPER# token.

Alle Debhelper-Befehle, die auf diese Art automatisch Kode erzeugen, lassen ihn durch den Parameter -n deaktiviert (siehe oben).

Beachten Sie, dass der eingefügte Kode Shell-Kode sein wird. Sie können ihn daher nicht direkt in einem Perl-Skript verwenden. Falls Sie ihn in ein Perl-Skript einbetten wollen, wird hier eine Möglichkeit dafür beschrieben (beachten Sie, dass über den Befehl »set« sichergestellt wird, dass $1, $2, etc. gesetzt sind):

```
  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("Das Debhelper-Skript scheiterte mit folgendem Fehlercode: ${exit_code}");
     } else {
         die("Das Debhelper-Skript wurde per Signal abgebrochen: ${signal}");
     }
  }
```

### Automatisches Erzeugen verschiedener Abhängigkeiten.
Einige Debhelper-Befehle könnten dazu führen, dass das erzeugte Paket von einigen anderen Paketen abhängt. Falls Sie beispielsweise dh_installdebconf(1) benutzen, wird Ihr Paket von Debconf abhängen müssen. Oder, falls Sie dh_installxfonts(1) verwenden, wird ihr Paket generell von einer bestimmten Version der Xutils abhängen. Den Überblick über diese verschiedenen Abhängigkeiten zu behalten kann lästig sein, da sie von Debhelpers Arbeitsweise abhängen, weswegen Debhelper eine Möglichkeit bietet, sie zu automatisieren.

As of compat 14, debhelper will automatically inject the relevant dependencies for you, since the dependency is done via a "relationship substvar" (see <https://lists.debian.org/debian-devel/2024/02/msg00230.html> and <https://lists.debian.org/debian-devel/2024/03/msg00030.html> for details).

In earlier compat levels, you have to manually specify the relevant substvars in the relevant fields. Typically, ${misc:Depends} for the Depends field and ${misc:Pre-Depends} for the Pre-Depends fields.

The variables listed here are entirely independent of the standard ${shlibs:Depends} generated by dh_makeshlibs(1), and the ${perl:Depends} generated by dh_perl(1). For compat 13 and earlier you will also have to add these to the respective fields when relevant.

### Paketbauverzeichnisse
Standardmäßig gehen alle Debhelper-Programme davon aus, dass das temporäre Verzeichnis, das zum Zusammenbau des Dateibaums in einem Paket benutzt wird, debian/Paket ist.

Manchmal wollen Sie möglicherweise ein anderes temporäres Verzeichnis benutzen. Dies wird durch den Schalters -P unterstützt. »dh_installdocs -Pdebian/tmp« wird zum Beispiel debian/tmp als temporäres Verzeichnis nutzen. Beachten Sie, dass die Debhelper-Programme nur auf ein einzelnes Paket auf einmal einwirken können, wenn Sie -P verwenden. Falls Sie ein Paket haben, das mehrere Binärpakete baut, müssen Sie zusätzlich den Schalter -p einsetzen, um anzugeben, auf welches Binärpaket sich das Debhelper-Programm auswirkt.

### Udebs
Debhelper beinhaltet Unterstützung für Udebs. Um ein Udeb mit Debhelper zu erstellen, fügen Sie dem Abschnitt des Pakets in debian/control »Package-Type: udeb« hinzu. Debhelper wird versuchen, Udebs zu erstellen, die der Debian-Installer-Richtlinie entsprechen, indem die erzeugten Paketdateien mit .udeb enden, keine Dokumentation in ein Udeb installiert wird und preinst-, postrm-, prerm- sowie config-Skripte etc. übersprungen werden.

## UMGEBUNGSVARIABLEN
Dieser Abschnitt beschreibt einige der Umgebungsvariablen, die das Verhalten von Debhelper beeinflussen oder mit denen Debhelper interagiert.

Es ist wichtig, darauf hinzuweisen, dass es echte Umgebungsvariablen (nicht nur einfache Makefile-Variablen) sein müssen, damit dies korrekt funktioniert. Um sie ordnungsgemäß in debian/rules anzugeben, müssen Sie sicherstellen, dass sie »export«iert werden, zum Beispiel »export DH_VERBOSE«.

DH_VERBOSE

Ist hier ein beliebiger (nicht-leerer) Wert gesetzt, arbeitet Debhelper im detailreichen Modus. Details finden Sie bei der Option -v / --verbose.

DH_QUIET

Ist hier ein nicht-leerer Wert gesetzt, arbeitet Debhelper im stillen Modus. Es wird wird weder Befehle ausgeben, die das Bausystem der Ursprungsautoren aufrufen, noch wird dh auflisten, welche Unterbefehle aufgerufen werden. Abhängig vom benutzten Bausystem wird auch dieses weniger Details ausgeben. Dadurch wird es einfacher, wichtige Nachrichten zu erkennen, die Ausgabe wird jedoch als Build-Protokoll ziemlich nutzlos. Wird ignoriert, wenn DH_VERBOSE ebenfalls gesetzt oder -v / --verbose übergeben wird.

DH_COMPAT

gibt vorübergehend an, auf welcher Kompatibilitätsstufe Debhelper ausgeführt werden soll und setzt dabei die standardmäßige Kompatibilitätsstufe aus dem Quellpaket außer Kraft.

DH_NO_ACT

auf 1 gesetzt, um Modus ohne Aktion zu aktivieren.

DH_OPTIONS

Alle Debhelper-Werkzeuge werden die in dieser Variable aufgeführten Argumente vor ihren eigenen Befehlszeilenargumenten auswerten (als ob sie den Befehlszeilenargumenten vorangestellt worden wären). Leider unterstützen einige von Dritten bereitgestellte Werkzeuge diese Variable möglicherweise nicht und werden diese Befehlszeilenargumente ignorieren. Wenn dh(1) benutzt wird, können ihm Optionen übergeben werden, die es an jeden Debhelper-Befehl weitergibt, was im Allgemeinen besser ist, als DH_OPTIONS zu verwenden.

DH_ALWAYS_EXCLUDE

Falls gesetzt, fügt dies den Wert der Variablen den -X-Optionen aller Befehle hinzu, welche die Option -X unterstützen. Außerdem wird dh_builddeb für alles in Ihrem Paketbaubaum, das dem Wert entspricht, rm -rf ausführen. Dies kann nützlich sein, wenn Sie aus einem CVS-Quellverzeichnisbaum bauen. In diesem Fall verhindert das Setzen von DH_ALWAYS_EXCLUDE=CVS, dass sich irgendwelche CVS-Verzeichnisse in das Paket einschleichen, das Sie bauen. Oder, falls ein Paket einen Quell-Tarball hat, der (unklugerweise) CVS-Verzeichnisse enthält, möchten Sie möglicherweise DH_ALWAYS_EXCLUDE=CVS in debian/rules exportieren, damit es wirksam ist, wo auch immer Ihr Paket gebaut wird.

Mehrere Dinge, die ausgeschlossen werden sollen, können mit Doppelpunkten getrennt werden, wie in DH_ALWAYS_EXCLUDE=CVS:.svn.

DH_EXTRA_ADDONS

Falls gesetzt, fügt dies die angegebenen Dh-Erweiterungen hinzu, die an den entsprechenden Stellen in den Befehlssequenzen ausgeführt werden. Dies entspricht der Angabe der auszuführenden Erweiterung mit dem Schalter --with in der Datei »debian/rules«. Alle --without-Aufrufe, die in dieser Umgebungsvariable eine Erweiterung festlegen, werden nicht ausgeführt. Dies ist für die Benutzung durch nachgeschaltete Distributionen oder spezielle lokale Konfigurationen gedacht, die während mehrerer Bauvorgänge eine Debhelper-Erweiterung ausführen müssen, ohne dass eine große Anzahl von Regeldateien bearbeitet werden muss. Falls überhaupt möglich, sollte dies zugunsten eines --with-Schalters in der Datei »rules« vermieden werden.

DH_COLORS, DPKG_COLORS

Diese Variablen können benutzt werden, um zu steuern, ob Debhelper-Befehle in ihrer Textausgabe Farben benutzen sollen. Sie können auf »always«, »auto« (die Voreinstellung) oder »never« gesetzt werden. Beachten Sie, dass DPKG_COLOR auch mehrere mit Dpkg verbunden Werkzeuge beeinflusst und Debhelper es unter der Annahme benutzt, dass Sie dieselbe Farbeinstellung für Dpkg und Debhelper benutzen wollen. In dem unwahrscheinlichen Fall, dass Sie für Debhelper eine andere Farbeinstellung möchten, können Sie DH_COLORS statt oder zusätzlich zu DPKG_COLORS verwenden.

NO_COLOR

Falls nicht explizit um Farbe gebeten wurde (sowohl DH_COLORS als auch DPKG_COLORS sind nicht gesetzt), führt die Anwesenheit dieser Umgebungsvariablen dazu, dass die Standardfarbeinstellung auf »never« gesetzt wird. Die Variable ist gemäß <https://no-color.org/> definiert. In diesem Projekt werden die Umgebungsvariablen (wie DH_COLORS) als explizite Farbanfrage betrachtet.

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

Standardmäßig (in jeder nicht missbilligten Kompatibilitätsstufe) wird Debhelper diese Schalter automatisch mittels dpkg-buildflags(1) setzen, wenn sie nicht gesetzt sind. Falls Sie die voreingestellten Schalter ändern wollen, benutzen Sie dazu die Funktionalität von dpkg-buildflags(1) (z.B. DEB_BUILD_MAINT_OPTIONS=hardening=all oder DEB_CPPFLAGS_MAINT_APPEND=-DCUSTOM_MACRO=true) statt die konkrete Variable direkt zu setzen.

HOME, XDG_*

In Kompatibilitätsstufe 13 und darüber werden diese Umgebungsvariablen zurückgesetzt, bevor das Bausystem der Originalautoren via dh_auto_* angeworfen wird. Die HOME- (dh_auto_*-Hilfsprogramme) und die XDG_RUNTIME_DIR-Variable (nur dh_auto_test) werden auf ein beschreibbares Verzeichnis gesetzt. Alle anderen Variablen und XDG_RUNTIME_DIR (außer während des dh_auto_test) werden geleert. Die Verzeichnisse werden leer erzeugt und zwischen den dh_auto_*-Aufrufen wiederverwendet. Jeglicher Inhalt wird weiter bestehen, bis er explizit gelöscht oder dh_clean aufgerufen wird.

DEB_BUILD_OPTIONS

Die Beschreibung dieser Umgebungsvariable entnehmen Sie bitte "Unterstützte Optionen in DEB_BUILD_OPTIONS". Bitte beachten Sie, dass diese Variable von Paketbetreuern in ihren debian/rules nicht geändert werden sollte, um das Verhalten von Debhelper zu beeinflussen. Stattdessen sollen die fraglichen Funktionsmerkmale direkt abgeschaltet werden (etwa durch Außerkraftsetzen der betreffenden Werkzeuge).

DEB_BUILD_MAINT_OPTIONS

Dies ist eine Dpkg-spezifische Umgebungsvariable (siehe dpkg-buildflags(1)). Die Debhelper-Suite ignoriert sie kommentarlos. Sie ist hier dokumentiert, weil ihr Name DEB_BUILD_OPTIONS ähnelt, was zu der falschen Annahme verleiten kann, dass Debhelper die Variable genauso auf die Variable reagiert.

### Unterstützte Optionen in DEB_BUILD_OPTIONS
Die Debhelper-Suite reagiert auf die folgenden Optionen in DEB_BUILD_OPTIONS:

dherroron=obsolete-compat-levels

Dieser Wert ist Debhelper-spezfisch. Wenn dherroron vorhanden und auf obsolete-compat-levels gesetzt ist, werden die Debhelper-Werkzeuge die Missbilligungswarnungen für die in naher Zukunft zu entfernenden Kompatiblitätsstufen zu Fehlern erheben.

Dies hilft bei automatischen Überprüfungen, ob Kode auf veralteten Kompatibilitätsstufen basiert, die bald entfernt werden sollen.

Die Option ist für Testzwecke gedacht, aber nicht für Produktiveinsatz.

nostrip

Dieser Wert ändert den Inhalt der Debs, die gebaut werden. Die .deb-Pakete, die unter Anwesenheit dieses Werts gebaut werden, werden nicht Bit für Bit reproduzierbar sein, was bei einem gewöhnlichen Paket der Regelfall ist. Durch diesen Wert werden die offiziellen Debhelper-Werkzeuge dazu gebracht, Aktionen und Hilfsprogramme zum Entfernen, Abkoppeln oder Deduplizieren von Fehlersuchsymbolen in ELF-Binärdateien zu überspringen.

Dieser Wert betrifft dh_dwz(1) und dh_strip(1).

nocheck

Dieser Wert führt dazu, dass die offiziellen Debhelper-Bausysteme die Ausführung von Test-Suiten der Originalautoren überspringen. Paketbetreuer, die versuchen, diese Tests zu umgehen, sollten sich hierauf nicht verlassen. Stattdessen können sie ein leeres Override-Ziel angeben, um dh_auto_test zu überspringen.

Dieser Wert betrifft dh_auto_test(1).

nodoc

Dieser Wert ändert den Inhalt der Debs, die gebaut werden. Die .deb-Pakete, die unter Anwesenheit dieses Werts gebaut werden, werden nicht Bit für Bit reproduzierbar sein, was bei einem gewöhnlichen Paket der Regelfall ist. Dieser Wert wird mehrere Debhelper-Tools anweisen, die Installation von Dokumentation wie Handbuchseiten oder von den Originalautoren bereitgestellte Dokumentation auszulassen. Außerdem werden die Werkzeuge es ignorieren, wenn die deklarierte Dokumentation fehlt, unter der Annahme, dass sie nicht gebaut wurde.

Dieser Wert betrifft Werkzeuge wie dh_installdocs(1), welches weiß, dass es mit Dokumentation arbeitet.

notrimdch

Dieser Wert ändert den Inhalt der Debs, die gebaut werden. Die .deb-Pakete, die unter Anwesenheit dieses Werts gebaut werden, werden nicht Bit für Bit reproduzierbar sein, was bei einem gewöhnlichen Paket der Regelfall ist. Dieser Wert bewirkt, dass dh_installchangelogs(1) arbeitet, als ob es mit --no-trim aufgerufen worden wäre. Damit wird erzwungen, keine alten Einträge aus Changelogs zu entfernen.

noautodbgsym, noddebs

Der offizielle Name ist noautodbgsym. Die noddebs-Variante wird aus historischen Gründen akzeptiert. Dieser Wert veranlasst Debhelper, die automatische Erzeugung der Fehlersuchsymbol-Pakete zu unterlassen.

Dieser Wert beeinflusst dh_strip(1).

parallel=N

Dieser Wert erlaubt es Debhelper, bis zu N Threads oder Prozesse (eingeschränkt durch Parameter wie --no-parallel und --max-parallel=M) zu verwenden. Nicht alle Debhelper-Werkzeuge arbeiten parallel und können die Anfrage daher kommentarlos ignorieren. Dieser Wert betrifft viele Debhelper-Werkzeuge. Vor allem dh_auto_* wird versuchen, das zugrundeliegende Bausystem der Originalautoren mit dieser Anzahl an Threads auszuführen.

terse

Dieser Wert wird die offiziellen Debhelper-Bausysteme zu einer knappen, weniger ausführlichen (daher »terse«) Ausgabe animieren. Seine Wirkung hängt davon ab, inwieweit das Bausystem der Originalautoren und das von Debhelper solche Funktionsmerkmale unterstützen. Dieser Wert betrifft die meisten dh_auto_*-Werkzeuge direkt. Für Befehle, die vom Debhelper-Paket bereitgestellt werden führt es dazu, das sie so arbeiten, als ob die Umgebungsvariable DH_QUIET nicht leer wäre.

Unbekannte Schalter werden stillschweigend ignoriert.

Beachten Sie, dass Debhelper-ähnliche Werkzeuge oder Bausysteme von Drittherstellern unterschiedlich auf die oben genannten Schalter reagieren. Das hängt davon ab, wie die Werkzeuge im Detail implementiert sind.

## SIEHE AUCH
debhelper-compat-upgrade-checklist(7)

Liste der unterstützten Kompatibilitätsstufen und eine Upgrade-Prüfliste für jede davon.

/usr/share/doc/debhelper/examples/

eine Zusammenstellung von debian/rules-Beispieldateien, die Debhelper benutzen.

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

Debhelper-Website.

## ÜBERSETZUNG
Diese Übersetzung wurde mit dem Werkzeug po4a <http://po4a.alioth.debian.org/> durch Chris Leick c.leick@vollbio.de und das deutsche Debian-Übersetzer-Team im Dezember 2011 erstellt.

Bitte melden Sie alle Fehler in der Übersetzung an debian-l10n-german@lists.debian.org oder als Fehlerbericht an das Paket debhelper.

Sie können mit dem folgenden Befehl das englische Original anzeigen man -L en Abschnitt Handbuchseite

## AUTOR
Joey Hess <joeyh@debian.org>


debhelper.fr

package: debhelper

title: debhelper.fr(7)

text:
# debhelper.fr(7)

## NOM
debhelper – Ensemble d'outils regroupés sous le nom de debhelper

## SYNOPSIS
dh_* [-v] [-a] [-i] [--no-act] [-ppaquet] [-Npaquet] [-Ptmpdir]

## DESCRIPTION
Debhelper facilite la construction des paquets Debian. La philosophie qui sous-tend debhelper est de fournir une collection de petits outils simples et facilement compréhensibles qui seront exploités dans debian/rules pour automatiser les tâches courantes liées à la construction des paquets, d'où un travail allégé pour le responsable. Dans une certaine mesure, cela signifie également que ces outils peuvent être adaptés aux modifications éventuelles de la Charte Debian. Les paquets qui utiliseront debhelper ne nécessiteront qu'une simple reconstruction pour être conformes aux nouvelles règles.

Un fichier debian/rules typique, exploitant debhelper, appellera séquentiellement plusieurs des commandes de debhelper ou bien utilisera dh(1) pour automatiser ce processus. Des exemples de fichiers debian/rules qui exploitent debhelper se trouvent dans /usr/share/doc/debhelper/examples/

Pour créer un nouveau paquet Debian en utilisant debhelper, il suffit de copier un des fichiers d'exemple et de le modifier manuellement. Il est possible également d'essayer le paquet dh-make qui contient une commande dh_make automatisant partiellement le processus. Pour se familiariser avec ces concepts, le paquet Debian maint-guide contient un cours sur la construction d'un premier paquet avec debhelper.

Except where the tool explicitly denotes otherwise, all of the debhelper tools assume that they run from the root directory of an unpacked source package. This is so they can locate files like debian/control when needed.

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

### Commandes obsolètes
Quelques commandes de debhelper sont obsolètes et ne devraient plus être utilisées.

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

Noter que s'il n'y a qu'un paquet binaire listé dans debian/control, debhelper utilisera debian/toto lorsqu'il n'y a aucun fichier debian/paquet.toto. Dans les niveaux de compatibilité antérieurs à compat\ 15, cette solution de repli se produit aussi pour le premier paquet binaire listé dans debian/control quand il y plusieurs paquets binaires. Cependant, c'est une bonne idée de garder le préfixe paquet., car c'est plus explicite et requis également lors de la mise à niveau vers compat\ 15.

En plus, il existe des cas particuliers où debhelper se repliera toujours sur une version sans préfixe. Il y a des cas comme debian/copyright ou debian/changelog où les fichiers sont généralement utilisés et nécessaires à tous les paquets binaires.

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

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

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

### Substitutions dans les fichiers de configuration de debhelper
À partir du niveau de compatibilité 13, il est possible d'utiliser des substitutions simples dans les fichiers de configuration de debhelper pour les outils suivants :

- dh_clean

- dh_install

- dh_installcatalogs

- dh_installdeb

- dh_installdirs

- dh_installdocs

- dh_installexamples

- dh_installinfo

- dh_installman

- dh_installwm

- dh_link

- dh_missing

- dh_ucf

Toutes les variables de substitution sont de la forme ${toto} et les accolades sont obligatoires. Les noms de variable sont sensibles à la casse et sont constitués de caractères alphanumériques (a-zA-Z0-9), tirets (-), tirets bas (_) et deux points (:). Le premier caractère doit être alphanumérique.

Si vous avez besoin d'un dollar littéral qui ne déclenche pas une substitution, il est possible d'utiliser soit la substitution ${Dollar} soit la séquence ${}.

Les développements suivants sont disponibles :

DEB_HOST_*, DEB_BUILD_*, DEB_TARGET_*

Se développent à la valeur dpkg-architecture(1) adéquate (comme dpkg-architecture -qVARIABLE_HERE). En cas de doute, la variante DEB_HOST_* est celle qui fonctionnera à la fois pour les constructions natives et croisées

Pour des raisons de performance, debhelper tentera de résoudre d'abord ces noms à partir de l'environnement avant de consulter dpkg-architecture(1). Cela est mentionné principalement dans un esprit de complétude, car cela n'a pas d'importance dans la plupart des cas.

Dollar

Se développe en un symbole $ littéral unique. Ce symbole ne sera jamais considéré comme faisant partie d'une variable de substitution. C'est-à-dire :

```
   # Déclenche une erreur
   ${NO_SUCH_TOKEN}
   # Se développe à la valeur littérale « ${NO_SUCH_TOKEN} »
   ${Dollar}{NO_SUCH_TOKEN}

```

Cette variante est l'équivalent de la séquence ${} et les deux sont interchangeables.

Newline, Space, Tab

Se développent respectivement en un seul caractère ASCII saut de ligne, une espace et une tabulation. Cela peut être utile s'il est nécessaire d'inclure un caractère d'espacement littéral (par exemple une espace) là où il serait autrement dépouillé ou utilisé comme un séparateur.

env:NOM

Se développe en la variable d'environnement NOM. La variable d'environnement doit être réglée (mais elle peut être réglée à une chaîne vide).

Notez que toutes les variables doivent se développer à une valeur définie. Par exemple, si debhelper voit ${env:TOTO}, alors, il affirme que la variable d'environnement TOTO est réglée (elle peut être réglée à une chaîne vide).

Contraintes des substitutions

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

Note the limit is per token. Every helper decides its own definition of a token. The common case of files like debian/package.install, each token is a file/path name.

Contraintes des substitutions : filtrage

La fonction de substitution intégrée ne peut pas être utilisée pour « filtrer » le contenu. Une tentative pour créer des «\ commentaires\ » ou des « lignes vides » avec la substitution aura pour conséquence que ces variables seront considérées comme un item à part entière avec le contenu donné.

Si vous souhaitez utiliser un filtrage, vous devriez envisager d'utiliser un fichier de configuration de debhelper exécutable avec dh-exec comme interpréteur. L'outil dh-exec prend en charge plusieurs fonctions prêtes à l'emploi. Cependant, gardez à l'esprit que dh-exec a sa propre logique de substitution qui peut interagir avec celle de debhelper.

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

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

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

- Le fichier de configuration exécutable doit se terminer avec succès (le code de retour doit l'indiquer).

- À partir du niveau de compatibilité 13, la sortie sera sujette à des substitutions (voir "Substitutions dans les fichiers de configuration de debhelper") lorsque l'outil les prend en charge. N'oubliez d'être prudent si votre générateur fournit aussi des substitutions parce que cela peut provoquer des confusions inutiles. En particulier, l'outil dh-exec, fréquemment utilisé, possède sa propre prise en charge des substitutions. Autrement, la sortie sera utilisée exactement telle quelle. En particulier, debhelper ne développera pas les jokers, ni ne supprimera les commentaires ou les espaces de la sortie qu'il lit. L'outil dh-exec a un filtre de sortie activé par défaut qui retire ce genre de choses.

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 bavard : afficher les commandes qui modifient le répertoire de construction du paquet. Notez que le mode bavard peut aussi lister d'autres commandes « internes » qui n'affectent pas directement 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

Obsolète : cette option n'a pas d'utilité pratique dans compat\ 15 ou ultérieur dans la mesure où le comportement qu'elle affecte a été supprimé dans compat 15. Cette option, peu utilisée, indique à debhelper le nom du « paquet principal » pour lequel les fichiers debian/toto peuvent être utilisés à la place des fichiers habituels debian/paquet.toto. Par défaut, debhelper considère que le « paquet principal » est le premier paquet énuméré dans le fichier debian/control.

-O=option|ensemble

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

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

-n

Ne pas modifier les scripts de maintenance du paquet (postinst, postrm, etc.)

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

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

-A, --all

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

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

-Sprocessus de construction, --buildsystem=processus_de_construction

Oblige à utiliser le processus de construction indiqué au lieu de tenter de déterminer automatiquement celui qui pourrait être utilisable pour le paquet. Indique none comme buildsystem pour désactiver la sélection automatique.

-Drépertoire, --sourcedir=répertoire, --sourcedirectory=répertoire

Considère que les sources du paquet sont situées dans le répertoire indiqué plutôt qu'au plus haut niveau de l'arborescence du paquet source. Attention : La variante --sourcedir correspond à une option du même nom dans dh_install et dh_missing, etc., pour des raisons historiques. Alors qu'elles ont le même nom, elles ont des objectifs très différents et, dans certains cas, cela peut provoquer des erreurs quand cette variante est passée à dh (quand ensuite il le passe à tous les outils).

-B[répertoire], --builddir=[répertoire], --builddirectory=[répertoire]

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

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

--parallel, --no-parallel

Détermine si la construction parallèle doit être utilisée, si le système sous-jacent le permet. Le nombre de tâches parallèles est contrôlé, lors de la construction, par la variable d'environnement DEB_BUILD_OPTIONS ("Charte Debian, section 4.9.1"). Ce nombre peut également être soumis aux limites spécifiques du système de construction. Si aucune de ces options n'est précisée, debhelper active la parallélisation par défaut (--parallel) dans le niveau de compatibilité 10 (ou supérieur), et la désactive (--no-parallel) dans les autres niveaux.

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

--max-parallel=maximum

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

--reload-all-buildenv-variables

Par défaut, dh(1) calcule plusieurs variables d'environnement (par exemple en utilisant dpkg-buildflags(1)) et les met en cache pour éviter que tous les outils dh_auto_* les recalculent. Lorsque cette option est passée, l'outil réel dh_auto_* ignorera le cache de dh(1) et déclenchera une reconstruction de ces variables. Cela est utile dans le cas très rare où le paquet requiert de multiples constructions mais avec des options ...FLAGS différentes. Un exemple concret pourrait être la nécessité de modifier le paramètre -0 dans CFLAGS dans la seconde construction.

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

```

Sans --reload-all-buildenv-variables dans le second appel à dh_auto_configure(1), la modification dans DEB_CFLAGS_MAINT_APPEND pourrait être ignorée parce que dh_auto_configure(1) pourrait utiliser la valeur mise en cache de CFLAGS fixée par dh(1).

Cette option est seulement disponible avec debhelper (>= 12.7~) quand le paquet utilise le niveau de compatibilité 9 ou supérieur.

--list, -l

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

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

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

```
  Build-Depends: debhelper-compat (= 13)
```

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

Veuillez noter que debhelper ne fournit pas debhelper-compat pour les niveaux experimental ou bêta. Les paquets qui souhaitent expérimenter ces niveaux de compatibilité doivent mettre le niveau de compatibilité dans le champ X-DH-Compat de la section Source du fichier debian/control (ou si c'est seulement pour des commandes choisies, la variable d'environnement DH_COMPAT).

Historiquement, debhelper nécessitait d'indiquer le niveau de compatibilité dans le fichier debian/compat, et debhelper jusqu'à la version 14 continue à le comprendre pour des raisons de rétrocompatibilité. Pour utiliser cette méthode, le fichier 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 une version de 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~)
```

Notez que vous devez utiliser exactement une méthode pour spécifier le niveau de compatibilité de debhelper par défaut du paquet. Chaque fois que c'est possible, la dépendance de construction debhelper-compat est recommandée.

Au besoin, la variable d'environnement DH_COMPAT peut être utilisée pour outrepasser le niveau de compatibilité pour une commande donnée. Cette fonction est surtout utile pour mettre à niveau temporairement quelques commandes vers un nouveau niveau de compatibilité ou pour garder certaines commandes à un niveau de compatibilité inférieur. Il vaut mieux utiliser cette fonction avec modération parce qu'elle introduit effectivement des cas particuliers dans le fichier debian/rules qui peuvent être déconcertants pour les responsables ou les réviseurs (ou, à long terme, pour vous-même).

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
La liste des niveaux de compatibilité pris en charge et la liste de contrôle de mise à niveau ont été déplacées dans debhelper-compat-upgrade-checklist(7).

## REMARQUES

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

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.

When inserting the #DEBHELPER# token into a script, consider whether any of the hand written code has a compelling reason to appear before the #DEBHELPER# token. The #DEBHELPER# token will generally contain the code that start (postinst) or stop (prerm/preinst) any services the package is providing. Often (but not always), it is better to let the code from #DEBHELPER# run first. Common exceptions include things like set -e, initializing debconf (when needed) and special-cases like generation or hand-written management of configuration files. These things should generally occur before the #DEBHELPER# token.

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.

As of compat 14, debhelper will automatically inject the relevant dependencies for you, since the dependency is done via a "relationship substvar" (see <https://lists.debian.org/debian-devel/2024/02/msg00230.html> and <https://lists.debian.org/debian-devel/2024/03/msg00030.html> for details).

In earlier compat levels, you have to manually specify the relevant substvars in the relevant fields. Typically, ${misc:Depends} for the Depends field and ${misc:Pre-Depends} for the Pre-Depends fields.

The variables listed here are entirely independent of the standard ${shlibs:Depends} generated by dh_makeshlibs(1), and the ${perl:Depends} generated by dh_perl(1). For compat 13 and earlier you will also have to add these to the respective fields when relevant.

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

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

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

## VARIABLES D'ENVIRONNEMENT
Cette section décrit certaines des variables d'environnement qui influencent le comportement de debhelper ou avec lesquelles debhelper est en interaction.

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

DH_VERBOSE

Définir à une valeur non vide pour activer le mode bavard. Consultez l'option -v/--verbose pour des détails.

DH_QUIET

Définir à une valeur non vide pour activer 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 ou si -v/--verbose est passée.

DH_COMPAT

Indiquer temporairement le niveau de compatibilité avec lequel debhelper doit fonctionner. Cette valeur supplante le niveau de compatibilité par défaut du paquet source.

DH_NO_ACT

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

DH_OPTIONS

Tous les outils de debhelper analyseront les arguments de la ligne de commande listés dans cette variable avant toute option de commande (comme s'ils avaient été ajoutés au début des arguments de la ligne de commande). Malheureusement, certains outils tiers peuvent ne pas prendre en compte cette variable et ignoreront ces arguments. En utilisant dh(1), des options peuvent être passées à chaque commande debhelper, ce qui est généralement mieux que d'utiliser DH_OPTIONS.

DH_ALWAYS_EXCLUDE

Si cette variable possède une valeur, elle sera ajoutée à l'option -X de toutes les commandes qui admettent cette option. De plus, dh_builddeb fera un rm -rf pour chaque chose correspondant à la valeur dans l'arbre de construction de paquet. Cela peut être utile pour construire un paquet à partir d'une arborescence CVS. Dans ce cas, le réglage de DH_ALWAYS_EXCLUDE=CVS empêchera les répertoires CVS d'interférer subrepticement dans le paquet en construction. Ou, si un paquet possède une source compressée, (maladroitement) présente dans un répertoire CVS, il peut être utile d'exporter DH_ALWAYS_EXCLUDE=CVS dans debian/rules, pour que cette variable soit prise en compte quel que soit l'endroit où le paquet est construit.

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

DH_EXTRA_ADDONS

Les rajouts à dh indiqués seront exécutés lors de la séquence de commandes. Cela équivaut à les indiquer avec le drapeau --with dans le fichier debian/rules. Les rajouts précédés de --without ne seront pas exécutés, même s'ils sont indiqués dans cette variable d'environnement. Cela est prévu pour être utilisé par les dérivées ou les configurations locales spécifiques qui ont besoin d'un rajout lors de plusieurs construction, sans avoir à modifier un grand nombre de fichier rules. Il est préférable d'éviter cette méthode et d'utiliser plutôt les drapeaux --with dans le fichier rules.

DH_COLORS, DPKG_COLORS

Ces variables peuvent être utilisées pour contrôler comment les commandes de debhelper peuvent utiliser la couleur dans leurs sorties textuelles. Les réglages peuvent être « always », « auto » (par défaut) ou « never ». Notez que DPKG_COLOR affecte aussi un certain nombre d'outils liés à dpkg et debhelper l'utilise en supposant que vous voulez les même réglages de couleur pour dpkg et debhelper. Au cas où vous voudriez un autre jeu de couleurs pour debhelper, vous pouvez utiliser DH_COLORS à la place ou en plus de DPKG_COLORS.

NO_COLOR

Si aucune demande explicite de couleur n'a été passée (par exemple, ni DH_COLORS, ni DPKG_COLORS n'ont été configurées), la présence de cette variable d'environnement fera que le réglage des couleurs par défaut sera « never ». Cette variable est définie conformément à <https://no-color.org/>. Dans ce projet, les variables d'environnement (comme DH_COLORS) sont considérées comme une demande explicite de couleur.

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

Par défaut (dans tout niveau de compatibilité non obsolète), debhelper réglera automatiquement ces paramètres en utilisant dpkg-buildflags(1) quand ils ne sont pas définis. S'il est nécessaire de changer les paramètres par défaut, veuillez utiliser les fonctions de dpkg-buildflags(1) pour le faire (par exemple, DEB_BUILD_MAINT_OPTIONS=hardening=all ou DEB_CPPFLAGS_MAINT_APPEND=-DCUSTOM_MACRO=true) au lieu de configurer directement les variables concrètes.

HOME, XDG_*

À partir du niveau de compatibilité 13, ces variables d'environnement sont réinitialisées avant d'invoquer le système de construction amont à l'aide des outils dh_auto_*. Les variables HOME (pour tout outil dh_auto_*) et XDG_RUNTIME_DIR (pour dh_auto_test seulement) seront réglées dans un répertoire accessible en écriture. Toutes les autres variables et XDG_RUNTIME_DIR (sauf durant dh_auto_test) seront vidées. Le répertoire HOME sera créé comme un répertoire vide mais il sera réutilisé entre les appels à dh_auto_*. Tout son contenu restera jusqu'à ce qu'il soit explicitement supprimé ou jusqu'à l'exécution de dh_clean.

DEB_BUILD_OPTIONS

Veuillez consulter "Paramètres pris en charge dans DEB_BUILD_OPTIONS" pour cet environnement. Veuillez noter que cette variable ne devrait pas être modifiée par les responsables de paquet dans debian/rules pour changer le comportement de debhelper. Ils devraient plutôt rechercher à désactiver la fonction correspondante directement (par exemple en surchargeant les outils spécifiques).

DEB_BUILD_MAINT_OPTIONS

C'est une variable d'environnement spécifique à dpkg (voir par exemple dpkg-buildflags(1)). La suite d'outils de debhelper l'ignore silencieusement. Cela est documenté ici parce qu'elle porte un nom identique à DEB_BUILD_OPTIONS, ce qui fait que certaines personnes pensent par erreur que debhelper réagit aussi à cette variable.

### Paramètres pris en charge dans DEB_BUILD_OPTIONS
La suite d'outils de debhelper réagit aux paramètres suivants dans DEB_BUILD_OPTIONS.

dherroron=obsolete-compat-levels

C'est une valeur spécifique à debhelper. Quand dherroron est présent et réglé à obsolete-compat-levels, alors les outils de debhelper présenteront dans les erreurs des alertes sur l'utilisation des niveaux de compatibilité anciens sur le point d'être obsolètes

C'est utile pour la vérification automatique de code se basant sur des niveaux de compatibilité dont la suppression est programmée.

Cette option est destinée aux tests et non aux constructions pour la production.

nostrip

Cette valeur changera le contenu des paquets .deb en construction. Les paquets .deb construits avec ce réglage ne seront donc pas reproductibles bit à bit par rapport à une construction normale en cas général. Cette valeur fera que les outils officiels de debhelper ignoreront les actions et les outils qui suppriment, détachent ou dédoublent les symboles de débogage dans les binaires ELF.

Cette valeur affecte dh_dwz(1) et dh_strip(1).

nocheck

Cette valeur fera que les systèmes de construction officiels de debhelper ignoreront l'exécution des suites de tests de l'amont. Les responsables de paquet cherchant à éviter l'exécution des tests de l'amont ne devraient pas recourir à cela. Ils peuvent plutôt ajouter une cible de réécriture vide pour ignorer dh_auto_test.

Cette valeur affecte dh_auto_test(1).

nodoc

Cette valeur changera le contenu des paquets .deb en construction. Les paquets .deb construits avec ce réglage ne seront donc pas reproductibles bit à bit par rapport à une construction normale en cas général. Cette valeur fera que plusieurs outils de debhelper ignoreront l'installation de documentation comme les pages de manuel ou la documentation fournie par l'amont. En plus, les outils ne sauront pas si la documentation déclarée est « missing » en partant du principe que la documentation n'a pas été construite.

Cette valeur affecte des outils comme dh_installdocs(1) qui sait qu'il travaille sur la documentation.

notrimdch

Cette valeur changera le contenu des paquets .deb en construction. Les paquets .deb construits avec ce réglage ne seront donc pas reproductibles bit à bit par rapport à une construction normale en cas général. Cette valeur fera que dh_installchangelogs(1) agira comme s'il avait été passé avec l'option --no-trim, l'obligeant à renoncer à supprimer les entrées anciennes des journaux de modification.

noautodbgsym, noddebs

Le nom officiel est noautodbgsym. La variante noddebs est acceptée pour des raisons historiques. Cette valeur fait que debhelper ignore la création des paquets de symboles de débogage générés automatiquement.

Cette valeur affecte dh_strip(1).

parallel=N

Cette valeur à permet debhelper d'utiliser jusqu'à N threads ou processus (soumis à des paramètres comme --no-parallel et --max-parallel=M). Tous les outils de debhelper ne fonctionnent pas avec des tâches parallèles et peuvent ignorer silencieusement la requête. Cette valeur affecte de nombreux outils de debhelper et en particulier dh_auto_* qui tentera d'exécuter le système de construction amont sous-jacent avec ce nombre de threads.

terse

Cette valeur fera que les systèmes de construction officiels de debhelper configurent les constructions de l'amont pour qu'elles soient laconiques (c'est-à-dire réduisent la prolixité de leurs sorties). Cela est subordonné à la prise en charge par les systèmes de construction de l'amont et de debhelper de ces fonctionnalités. Cette valeur affecte directement surtout les outils dh_auto_*. Pour les commandes fournies par le paquet debhelper, il fait aussi que les outils agissent comme si la variable d'environnement DH_QUIET n'était pas vide.

Les paramètres inconnus sont ignorés silencieusement.

Veuillez noter que les outils tiers dans le style de debhelper ou les systèmes de construction fournis par des tiers peuvent réagir ou non aux paramètres ci-dessus. Cela dépend généralement des détails d'implémentation des outils

## VOIR AUSSI
debhelper-compat-upgrade-checklist(7)

Liste des niveaux de compatibilité pris en charge et une liste de contrôle de mise à niveau pour chacun d'entre eux.

/usr/share/doc/debhelper/examples/

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

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

Le site internet de debhelper.

## AUTEUR
Joey Hess <joeyh@debian.org>

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

Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet debhelper.

Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C <section> <page_de_man> ».

branch: sisyphus