Ubuntu Manpage: debhelper - die Debhelper-Werkzeugsammlung

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

Solange nichts anderes angegeben wird, gehen alle Debhelper-Werkzeuge davon aus, dass sie aus dem
Wurzelverzeichnis eines entpackten Quellpakets ausgeführt werden. Dadurch können sie, wenn notwendig,
Dateien wie debian/control finden.

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-Add-on-Paket

       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

   Missbilligte 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 kompiziertere Formate.

Beachten Sie, dass Debhelper für das erste (oder einzige) in debian/control aufgeführte Binärpaket
debian/foo benutzen wird, wenn es keine debian/Paket.foo-Datei gibt. Oft ist es jedoch eine gute Idee,
das Präfix Paket. zu behalten, da es eindeutiger ist. Die Hauptausnahme davon bilden Dateien, die
Debhelper standardmäßig in jedem Binärpaket installiert, wenn es kein Paketpräfix besitzt (wie
debian/copyright oder debian/changelog).

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

Um Endlosschleifen und Ressourcenverschwendung zu vermeiden, bricht Debhelper mit einer Fehlermeldung ab,
falls der Text viele Ersetzungsvariablen (50) enthält oder sie über eine bestimmte Größe expandieren
(4096 Zeichen oder die dreifache Länge des Originaleingabe - je nachdem, was größer ist).

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.

Andernfalls wird die Ausgabe exakt so benutzt, wie sie ist. Insbesondere wird Debhelper Platzhalter
nicht expandieren oder Kommentare und Leerzeichen aus der Ausgabe entfernen.

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 alle Befehle, die das Paketbauverzeichnis ändern

--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äraketen 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
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 Umgebungen 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 Debhelper-Compat nicht für experimentelle oder Beta-Kompatibilitätsstufen
bereitstellt. Pakete, die mit diesen Kompatibilitätsstufen experimentieren, sollten debian/compat oder
DH_COMPAT verwenden.

Frühere Versionen von Debhelper benötigten die Angabe der Kompatibilitätsstufe in der Datei
debian/compat. Das aktuelle Debhelper unterstützt dies zum Zweck der Rückwärtskompatibilität weiterhin,
allerdings darf ein Paket eine Kompatibilitätsstufe nicht über mehrere Methoden gleichzeitig angeben. Um
diese Methode zu verwenden, sollte debian/compat die Kompatibilitätsstufe als einzelne Zahl enthalten und
keinen weiteren Inhalt. Falls Sie die Kompatibilitätsstufe mit dieser Methode angeben, wird Ihr Paket
auch eine passende versionierte Bauabhängigkeit mit der gleichen (oder einer höheren) Kompatibiltätsstufe
benötigen. Daher sollten Sie, falls Sie die Kompatibilitätsstufe 13 in debian/compat angeben,
sicherstellen, dass debian/control Folgendes enthält:

Build-Depends: debhelper (>= 13~)

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
Folgende Kompatibilitätsstufen sind verfügbar:

v7 Dieser Modus ist missbilligt.

Dies ist die unterste unterstützte Kompatibilitätsstufe.

Falls Sie ein Upgrade von einer vorhergehenden Kompatibilitätsstufe durchführen, überprüfen Sie bitte
debhelper-obsolete-compat(7).

v8 Änderungen gegenüber v7 sind:

- Befehle werden fehlschlagen anstatt zu warnen, wenn ihnen unbekannte Optionen übergeben
werden.

- dh_makeshlibs führt dpkg-gensymbols auf allen gemeinsamen Bibliotheken aus, für die es Shlib-
Dateien generiert, wobei Bibliotheken mit -X ausgeschlossen werden können. Außerdem werden
dpkg-gensymbols Bibliotheken an unüblichen Orten übergeben, ohne dass es diese vorher
verarbeitet haben wird, was dazu führen kann, dass sich einige Pakete nicht bauen lassen.

- dh erfordert, dass die auszuführende Sequenz als erster Parameter angegeben wird und
sämtliche Schalter danach kommen. Das heißt, Sie schreiben nicht »dh --foo $@«, sondern »dh
$@ --foo«.

- dh_auto_* bevorzugt Perls Module::Build gegenüber Makefile.PL.

Dieser Modus ist missbilligt.

v9 Änderungen gegenüber v8 sind:

- Multiarch-Unterstützung. Insbesondere gibt dh_auto_configure Multiarch-Verzeichnisse an
Autoconf in --libdir and --libexecdir weiter.

- dh kennt die üblichen Abhängigkeiten zwischen den Zielen in debian/rules. Daher wird »dh
binary« alle »build«-, »build-arch«-, »build-indep«-, »install«-Ziele etc. ausführen, die in
der Regeldatei stehen. Es ist nicht nötig, explizit ein binäres Ziel mit expliziten
Abhängigkeiten zu den anderen Zielen zu definieren.

- dh_strip komprimiert Debug-Symboldateien, um die Größe der installierten »-dbg«-Paketen zu
verringern.

- dh_auto_configure enthält keinen Quellpaketnamen in --libexecdir, wenn Autoconf benutzt wird.

- Standardmäßig aktiviert dh nicht --with=python-support.

(Hinfällig, da das Werkzeug dh_pysupport aus Debian Stretch entfernt wurde. Seit
Debhelper/10.3 aktiviert dh diese Sequenzerweiterung unabhängig von der Kompatibilitätsstufe
nicht mehr.)

- Alle dh_auto_*-Debhelper-Programme und dh setzen Umgebungsvariablen, die durch dpkg-
buildflags aufgelistet werden, sofern sie nicht bereits gesetzt sind.

- dh_auto_configure übergibt CFLAGS, CPPFLAGS und LDFLAGS von dpkg-buildflags an Perls
Makefile.PL und Build.PL.

- dh_strip legt getrennte Fehlersuchsymbole an einer Stelle ab, die auf ihrer Baukennzahl
basiert.

- Ausführbare Debhelper-Konfigurationsdateien werden ausgeführt und ihre Ausgabe wird als
Konfiguration benutzt.

Dieser Modus ist missbilligt.

v10 Änderungen gegenüber v9 sind:

- dh_installinit wird keine Datei namens debian/Paket mehr als Init-Skript installieren.

- dh_installdocs wird mit einem Fehler fehlschlagen, falls es Links entdeckt, die mit
--link-doc zwischen Paketen der Architektur »all« und nicht-»all« erzeugt wurden, da d
binNMUs beschädigt.

- dh_installdeb installiert keine vom Paketbetreuer bereitgestellte debian/Paket.shlibs-Datei
mehr. Dies wird stattdessen von dh_makeshlibs erledigt.

- dh_installwm weigert sich, ein beschädigtes Paket zu erstellen, falls keine Handbuchseite
gefunden wird (erforderlich, um die Alternative zum X-Window-Manager zu registrieren).

- --parallel ist Debhelpers Voreinstellung für alle Bausysteme, die paralleles Bauen
unterstützen. Dies kann entweder durch Verwendung von --no-parallel oder durch Übergabe von
--max-parallel mit einem Wert von 1 deaktiviert werden.

- Der Befehl dh wird keinen der veralteten Parameter zur »manuellen Sequenzsteuerung«
(--before, --after, etc.) akzeptieren. Bitte verwenden Sie stattdessen Aufhebungsziele
(override targts).

Nachträglich auf frühere Kompatibilitätsstufen angewandt: dh akzeptiert seit Debhelper/12.4
nichts davon mehr.

- Der Befehl dh wird keine Logdateien mehr benutzen, um zu protokollieren, welche Befehle
ausgeführt worden sind. Er wird aber trotzdem nachverfolgen, ob er selbst schon einmal in der
Bausequenz gelaufen ist und sie ggf. überspringen.

Die wichtigsten Auswirkungen davon sind:

- Hierdurch wird die Fehlersuche bei den Sequenzen install und/oder binary einfacher, da
sie nun einfach erneut ausgeführt werden können (ohne, dass ein vollständiger »Aufräum-
und Neubau«-Durchgang erforderlich ist).

- Der Pferdefuß hier liegt darin, dass dh_* nun nur noch nachverfolgt, was in einem
einzelnen Override-Ziel geschieht. Wenn alle Aufrufe eines angegebenen dh_cmd-Befehls im
selben Override-Ziel stattfinden, wird alles wie zuvor funktionieren.

Beispiel, bei dem es schiefgehen kann:

override_dh_foo:
dh_foo -pmein-Paket

override_dh_bar:
dh_bar
dh_foo --remaining

In diesem Fall wird der Aufruf von dh_foo --remaining außerdem mein-Paket enthalten, da
dh_foo -pmein-Paket in einem separaten Override-Ziel ausgeführt wird. Dieses Problem ist
nicht auf --remaining begrenzt, es umfasst außerdem -a, -i, etc.

- Der Befehl dh_installdeb maskiert nun die Zeilen in der Konfigurationsdatei maintscript für
die Shell. Dies war der ursprüngliche Gedanke, aber es funktionierte nicht, wie es sollte und
die Pakete begannen, sich auf die unvollständige Shell-Maskierung zu verlassen (z.B. das
Setzen von Dateinamen in Anführungszeichen).

- Voreinstellung für den Befehl dh_installinit ist nun --restart-after-upgrade. Für Pakete, die
das vorhergehende Verhalten erfordern, verwenden Sie bitte --no-restart-after-upgrade.

- Die autoreconf-Sequenz ist nun standardmäßig aktiviert. Bitte übergeben Sie --without
autoreconf an dh, falls dies für ein angegebenes Paket nicht erwünscht ist.

- Die systemd-Sequenz ist nun standardmäßig aktiviert. Bitte übergeben Sie --without systemd an
dh, falls dies für ein angegebenes Paket nicht erwünscht ist.

- Nachträglich entfernt: dh erstellt das Bauverzeichnis des Pakets nicht mehr, wenn die
Ausführung von Debhelper-Befehlen übersprungen wird. Dies hat keine Auswirkungen auf Pakete,
die nur mit Debhelper-Befehlen bauen, es könnte aber Fehler in Befehlen offenlegen, die nicht
in Debhelper enthalten sind.

Diese Kompatibilitätsfunktionalität hatte einen Fehler seit ihrer Aufnahme in
Debhelper/9.20130516, der sie im Kompatibilitätsmodus 9 und älter zum Scheitern brachte. Da
es in den fünf Jahren ihres Bestehens keine Berichte zu Problemen gab, die von diesem Fehler
verursacht wurden, wurde sie nicht überarbeitet, sondern entfernt.

v11 Von diesem Modus wird abgeraten.

Von der Kompatibilitätsstufe 11 wird für neue Pakete abgeraten, da sie vvon
Funktionalitätswechselwirkungen zwischen dh_installinit und dh_installsystemd betroffen ist, die dazu
führen, dass in manchen Fällen Dienste nicht korrekt laufen. Bitte erwägen Sie, stattdessen die
Kompatibilitätsstufen 10 oder 12 zu benutzen. Weitere Einzelheiten über das Thema sind in
Debian#887904 und <https://lists.debian.org/debian-release/2019/04/msg01442.html> verfügbar.

Änderungen gegenüber v10 sind:

- dh_installinit installiert keine service- oder tmpfile-Dateien mehr. Es erstellt auch keine
Betreuerskripte dafür. Bitte verwenden Sie das neue Hilfsprogramm dh_installsystemd.

- Die Hilfsprogramme dh_systemd_enable und dh_systemd_start wurden durch das neue Hilfsprogramm
dh_installsystemd ersetzt. Aus demselben Grund wurde auch die systemd-Sequenz für dh
entfernt. Wenn Sie das Hilfswerkzeug dh_installsystemd deaktivieren möchten, verwenden Sie
bitte ein leeres Override-Ziel.

Bitte beachten Sie, dass sich das Werkzeug dh_installsystemd in manchen Fällen (z.B. bei der
Verwendung des Parameters --name) geringfügig anders verhält.

- dh_installdirs erstellt keine debian/Paket-Verzeichnisse mehr, es sei denn, dies wird
ausdrücklich verlangt (oder es muss ein Unterverzeichnis darin erstellt werden).

Die große Mehrheit aller Pakete wird von dieser Änderung nicht betroffen sein.

- Das makefile-Bausystem übergibt nun INSTALL="install --strip-program=true" an make(1). Davon
abgeleitete Bausysteme (z. B. configure oder cmake) sind von dieser Änderung nicht betroffen.

- Das autoconf-Bausystem übergibt nun --runstatedir=/run an ./configure.

- Das cmake-Bausystem übergibt nun -DCMAKE_INSTALL_RUNSTATEDIR=/run an cmake(1).

- dh_installman wird nun vorzugsweise die Sprache anhand des Pfadnamens statt der Erweiterung
bestimmen.

- dh_auto_install wird jetzt nur das Zielverzeichnis erstellen, das es benötigt. Vorher hätte
es die Bauverzeichnisse für alle Pakete erstellt. Dies hat keine Auswirkungen auf Pakete, die
nur mit Debhelper-Befehlen bauen, es könnte aber Programmfehler in Befehlen offenlegen, die
nicht in Debhelper enthalten sind.

- Die Hilfsprogramme dh_installdocs, dh_installexamples, dh_installinfo und dh_installman
beenden sich jetzt mit Fehlermeldung, falls ihre Konfiguration ein Muster aufweist, das zu
nichts passt oder sich auf einen Pfad bezieht, den es nicht gibt.

Bekannte Ausnahmen umfassen das Bauen mit dem Profil nodoc, bei dem die obigen Werkzeuge
stillschweigend fehlschlagende Suchen mit Mustern erlauben,welche zur Angabe von
Dokumentation verwendet werden.

- Die Hilfsprogramme dh_installdocs, dh_installexamples, dh_installinfo und dh_installman
akzeptieren nun den Parameter --sourcedir mit derselben Bedeutung wie dh_install. Überdies
fallen sie jetzt, so wie dh_install, auf debian/tmp zurück.

Migrationshinweis: Ein Fehler in Debhelper 11 bis 11.1.5 führte fälschlicherweise dazu, dass
dh_installinfo --sourcedir ignoriert hat.

- Die Bausysteme perl-makemaker und perl-build übergeben -I. nicht mehr an Perl. Pakete, die
dieses Verhalten immer noch benötigen, können es durch Verwendung der Umgebungsvariable
PERL5LIB emulieren, z. B. durch Eintragen von export PERL5LIB=. in ihre »debian/rules«-Datei
(oder dergleichen).

- PERL_USE_UNSAFE_INC wird jetzt von dh oder den dh_auto_*-Werkzeugen nicht mehr gesetzt. Sie
diente als Übergangslösung, um zu verhindern, dass das gleichzeitige Bauen vieler Pakete
scheitert.

Beachten Sie, dass sie irgendwann komplett hinfällig wird, da die Ursprungsautoren
beabsichtigen, die Unterstützung für die Umgebungsvariable PERL_USE_UNSAFE_INC einzustellen.
Wenn es so weit ist, wird diese Variable nachträglich auch aus bestehenden
Kompatibilitätsstufen entfernt.

- Das Hilfsprogramm dh_makeshlibs wird nun mit einer Fehlermeldung beendet, falls Objdump nach
der Auswertung einer gegebenen Datei einen Rückgabewert ungleich null zurückliefert.

- Die Werkzeuge dh_installdocs und dh_installexamples können jezt die meiste Dokumentation in
einem anderen Pfad installieren, um die Empfehlung der Debian-Richtlinien §12.3 (seit Version
3.9.7) zu erfüllen.

Beachten Sie, dass diese Änderung nicht für dieses Quellpaket relevant ist und Sie zur
nächsten Änderung springen können, falls ein angegebenes Quellpaket nur ein einziges
Binärpaket in debian/control enthält oder keine -doc-Pakete dabei sind.

Standardmäßig werden diese Werkzeuge nun versuchen, ein »Hauptpaket für die Dokumentation«
(ab hier Hauptdokumentationspaket genannt) für jedes -doc-Paket zu bestimmen. Falls sie ein
derartiges Hauptdokumentationspaket finden, werden sie nun die Dokumentation in den Pfad
/usr/share/doc/Hauptdokumentationspaket im angegebenen Dokumentationspaket installieren. Das
heißt, der Pfad kann sich ändern, aber die Dokumentation wird immer noch im -doc-Paket
mitgeliefert.

Die Option --doc-main-package kann benutzt werden, wenn die automatische Erkennung
unzureichend ist oder um den Pfad auf seinen vorherigen Wert zurückzusetzen, falls es einen
Grund gibt, von der Empfehlung der Debian-Richlinien abzuweichen.

Manche Dokumentation wird von dieser Änderung nicht beeinflusst. Diese Ausnahmen umfassen die
Copyright-Dateien, README.Debian usw. Diese Dateien werden weiterhin im Pfad
/usr/share/doc/Paket installiert.

- Die Werkzeuge dh_strip und dh_shlibdeps verwenden keine Dateinamenmuster mehr, um zu
bestimmen, welche Dateien verarbeitet werden. Stattdessen öffnen sie die Datei und suchen
nach einem ELF-Header, um zu bestimmen, ob eine übergebene Datei ein gemeinsam benutztes
Objekt oder ein ausführbares binäres Programm ist.

Diese Änderung kann dazu führen, dass mehr Dateien als vorher verarbeitet werden.

v12 Änderungen gegenüber v11 sind:

- Das Werkzeug dh_makeshlibs erzeugt nun standardmäßig Shlibs-Dateien mit versionierter
Abhängigkeit. Das bedeutet, dass -VUpstream-Version (alias -V) nun die Voreinstellung ist.

Falls eine nicht versionierte Abhängigkeit in der Shlibs-Datei gewünscht wird, kann dies
stattdessen durch Übergabe von -VNone erreicht werden. Siehe aber auch dh_makeshlibs(1) für
die Vorbehalte gegen nicht versionierte Abhängigkeiten.

- Die Option -s (--same-arch) wurde entfernt. Bitte verwenden Sie stattdessen -a (--arch).

- Der Aufruf von dh_clean -k verursacht jetzt einen Fehler statt einer Warnung, es sei
missbilligt.

- Die Option --no-restart-on-upgrade in dh_installinit wurde entfernt. Bitte verwenden Sie den
neuen Namen --no-stop-on-upgrade.

- Es gab einen Fehler in den doit- und ähnlichen Funktionen von Debian::Debhelper::Dh_Lib, der
unter einem bestimmten Umstand zum Öffnen einer Shell führte. Dieser Fehler wurde nun
entfernt, wodurch Hilfsprogramme, die auf den Fehler setzen, mit der Meldung »command not
found« fehlschlagen.

- --list-missing und --fail-missing in dh_install wurden entfernt. Bitte verwenden Sie
dh_missing und die zugehörigen Optionen, die die durch andere Hilfsprogramme installierten
Dateien ebenfalls sehen können.

- Das Hilfsprogramm dh_installinit installiert die Konfiguration für das Init-System Upstart
nicht mehr. Stattdessen bricht es das Bauen ab, wenn es eine alte Upstart-Konfigurationsdatei
findet. Der Fehler soll den Paketbetreuer daran erinnern, sicherzugehen, dass die mit
vorherigen Versionen des Pakets mitgelieferten Konfigdateien (falls vorhanden) sauber
entfernt werden.

- Das Werkzeug dh_installdeb wird die Grundprüfung einiger dpkg-maintscript-helper(1)-Befehle
durchführen und sich mit einer Fehlermeldung beenden, falls die Befehle ungültig zu sein
scheinen.

- Das Werkzeug dh_missing wird nun auf --list-missing voreingestellt.

- Das Werkzeug dh_makeshlibs wird jetzt nur Bibliotheken an dpkg-gensymbols(1) übergeben, falls
die ELF-Binärdatei einen SONAME hat (enthält ».so«).

- Das Werkzeug dh_compress komprimiert keine Beispiele mehr (d. h. alles, was in
</usr/share/doc/Paket/examples> installiert ist).

- Die Standardsequenz in dh enthält nun standardmäßig dh_dwz und dh_installinitramfs. Dies
macht die Sequenzen dwz und installinitramfs überflüssig und sie werden mit einem Fehler
scheitern. Falls Sie diese Befehle überspringen wollen, fügen Sie bitte ein leeres Override-
Ziel in debian/rules ein (z.B. override_dh_dwz:).

- Die Bausysteme Meson und Autoconf setzen die Variable --libexecdir nicht mehr explizit und
verlassen sich auf die Voreinstellung des Bausystems – diese sollte /usr/libexec sein (per
FHS 3.0, angenommen in der Debian-Richtlinie 4.1.5).

Falls ein spezielles Paket der Ursprungsautoren nicht die korrekte Voreinstellung benutzt,
kann der Parameter oft manuell per dh_auto_configure(1) übergeben werden, etwa wie im
folgenden Beispiel:

override_dh_auto_configure:
dh_auto_configure -- --libexecdir=/usr/libexec

Beachten Sie das -- vor dem Parameter --libexecdir.

- Retroactively removed in debhelper/13.5:

The dh_installdeb tool would no longer installs the maintainer provided conffiles file as it
was deemed unnecessary. However, the remove-on-upgrade from dpkg/1.20 made the file relevant
again and dh_installdeb now installs it again in compat levels 12+.

- Das Werkzeug dh_installsystemd beruht nicht mehr auf dh_installinit, um Systemd-Dienste zu
handhaben, die über eine SysVinit-Alternative verfügen. In einem solchen Fall müssen jetzt
beide Werkzeuge benutzt werden, um sicherzustellen, dass der Dienst sowohl unter SysVinit als
auch unter Systemd sauber gestartet wird.

Falls Sie eine Methode haben, dh_installinit außer Kraft zu setzen (z. B. indem Sie es mit
--no-start aufrufen), dann werden Sie jetzt wahrscheinlich auch eine für dh_installsystemd
benötigen.

Diese Änderung lässt dh_installinit ein misc:Pre-Depends für init-system-helpers (>= 1.54~)
einspeisen. Bitte stellen Sie sicher, dass das Paket ${misc:Pre-Depends} in seinem Feld Pre-
Depends aufführt, bevor Sie ein Upgrade auf Kompatibilitätsstufe 12 durchführen.

- Das Drittherstellerwerkzeug dh_golang (aus dem Paket dh-golang) akzeptiert jetzt
standardmäßig die Variable DH_GOLANG_EXCLUDES für die Quelleninstallation in -dev-Paketen und
das nicht nur während des Bauprozesses. Bitte setzen Sie DH_GOLANG_EXCLUDES_ALL auf »false«,
um zum vorherigen Verhalten zurückzukehren. Einzelheiten und Beispiele finden Sie unter
Debian::Debhelper::Buildsystem::golang(3pm).

- dh_installsystemduser ist nun per Voreinstellung in der Standard-dh-Sequenz enthalten.

- Das Bausystem python-distutils ist jetzt entfernt worden. Bitte verwenden Sie stattdessen das
Drittanbieterbausystem pybuild.

v13 Dies ist der empfohlene Betriebsmodus.

Die Änderungen gegenüber v12 sind:

- Das Bausystem meson+ninja benutzt anstelle von ninja test nun meson test, wenn die Testsuite
ausgeführt wird. Alles, was dh_auto_test außer Kraft setzt und zusätzliche Parameter an das
Testausführungsprogramm der Ursprungsautoren übergibt, sollte überprüft werden, da meson test
auf der Befehlszeile nicht mit ninja test kompatibel ist.

- Alle Debhelper-ähnlichen Werkzeuge, die auf der offiziellen Debhelper-Bibliothek basieren
(einschließlich dh und den offiziellen dh_*-Werkzeugen) akzeptieren keine abgekürzten
Befehlsparameter mehr. Gleichzeitig sortiert dh nun Aufrufe zu überflüssigen
dh_*-Hilfsprogrammen sogar dann aus, wenn lange Befehlszeilenoptionen angegeben werden.

- Die ELF-bezogenen Debhelper-Werkzeuge (dh_dwz, dh_strip, dh_makeshlibs, dh_shlibdeps) werden
nun standardmäßig nur noch für architekturabhängige Pakete ausgeführt (d. h. sie werden von
*-indep-Zielen ausgeschlossen und standardmäßig mit -a übergeben). Falls Sie sie für
*-indep-Ziele benötigen, können Sie eine explizite Build-Depends in dh-sequence-elf-tools
hinzufügen.

- Das Drittanbieterbausystem gradle (aus dem Paket gradle-debian-helper) führt nun automatisch
eine von den Ursprungsautoren bereitgestellte Testsuite aus. Setzen Sie dh_auto_test außer
Kraft, um dieses Verhalten zu unterbinden.

- Das Werkzeug dh_installman beendet sich vorzeitig, falls es widersprüchliche Definitionen
einer Handbuchseite entdeckt. Dies kommt üblicherweise vor, wenn das Bausystem der
Ursprungsautoren eine komprimierte Version installiert und das Paket eine nicht komprimierte
Version der Handbuchseite in debian/package.manpages auflistet. Meist ist die einfachste
Lösung, die Handbuchseite aus debian/package.manpages zu entfernen (davon ausgehend, dass
beide Versionen identisch sind).

- Die dh_auto_*-Hilfsprogramme setzen nun die Umgebungsvariablen HOME und gebräuchliche
XDG_*-Variablen zurück. Wie damit umgegangen wird, können Sie Sie der Beschreibung für die
Umgebungsvariablen in "ENVIRONMENT" entnehmen.

Dieses Funktionsmerkmal hat sich zwischen Debhelper 13 und Debhelper 13.2 geändert.

- Der Befehl dh wird nun einen Fehler ausgeben, falls ein Override- oder Hook-Ziel für einen
veralteten Befehl in debian/rules (z.B. override_dh_systemd_enable:) vorhanden ist.

- Der Befehl dh_missing wird nun auf --fail-missing voreingestellt. Dies lässt sich zu einer
nicht-fatalen Warnung zurückändern, indem explizit --list-missing übergeben wird, wie es in
Kompatibilitätsstufe 12 war.

Falls Sie die Warnung gar nicht wollen, lassen Sie bitte den Aufruf von dh_missing weg. Falls
Sie den Befehlssequenzer dh benutzen, dann können Sie dies mit einem leeren Override-Ziel in
der Datei debian/rules oder dem passenden Paket erledigen. Zum Beispiel:

# Disable dh_missing
override_dh_missing:

- Der Befehlssequenzer dh führt nun in der Standardsequenz dh_installtmpfiles aus.
dh_installtmpfiles übernimmt die Handhabung von tmpfiles.d-Konfigurationsdateien.
Diesbezügliche Funktionalität in dh_installsystemd ist nun deaktiviert.

Beachten Sie, dass dh_installtmpfiles auf debian/Paket.tmpfiles reagiert, wo
dh_installsystemd einen Nahmen ohne das nachfolgende »s« benutzt hat.

- Viele dh_*-Werkzeuge unterstützen nun eine eingeschränkte Variablenexpandierung per
${foo}-Syntax. In vielen Fällen kann dies benutzt werden, um Pfade zu referenzieren, die
entweder Leerzeichen oder dpkg-architecture(1)-Werte enthalten. Obwohl es den Bedarf an
dh-exec(1) in einigen Fällen vermindern kann, ist es im Allgemeinen kein Ersatz für
dh-exec(1). Falls Sie filtern, umbenennen usw. möchten, wird das Paket weiterhin dh-exec(1)
benötigt.

Bitte lesen Sie "Ersetzungen in Debhelper-Konfigurationsdateien", um mehr über die Syntax und
verfügbare Ersetzungsvariablen zu erfahren. An Verfasser von dh_*-Werkzeugen: Die Ersetzung
und Expandierung ist Teil der Funktionen filearray und filedoublearray.

- Der Befehlssequenzer dh wird jetzt alle Hooks und Override-Ziele für dh_auto_test, dh_dwz und
dh_strip überspringen, wenn DEB_BUILD_OPTIONS die maßgeblichen nocheck-/nostrip-Optionen
aufführt.

Alle Pakete, die sich darauf verlassen, dass diese Ziele immer ausgeführt werden, sollten die
betroffene Logik aus diesen Zielen heraus verschieben. Z. B. müsste nicht-testbezogener
Paketierungscode von override_dh_auto_test nach execute_after_dh_auto_build oder
execute_before_dh_auto_install verschoben werden.

- Das cmake-Bausystem übergibt nun -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON an cmake(1), um den
automatischen Installationsprozess zu beschleunigen. Falls Sie aus irgendeinem Grund beim
alten Verhalten bleiben möchten, übersteuern Sie den Schalter:

dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...

v14 Diese Kompatibilitätsstufe ist immer noch für die Entwicklung offen. Verwenden Sie sie mit Vorsicht.

Änderungen gegenüber v13 sind:

- Das cmake-Bausystem übergibt nun -DCMAKE_SKIP_RPATH=ON und -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
an cmake(1), um einige Probleme mit der Reproduzierbarkeit zu beheben.

This can cause issues with running binaries directly from the build directories as they might
now require a manually set LD_LIBRARY_PATH. If you need to override this change, we recommend
that you try to pass the -DCMAKE_SKIP_RPATH=OFF option first to see if that fixes the problem
(leaving CMAKE_BUILD_RPATH_USE_ORIGIN at its new default). This should undo the need for
LD_LIBRARY_PATH and avoid the reproducibility issues on Linux, where $ORIGIN is supported by
the runtime linkers.

- The tool dh_installsysusers is now included in the default sequence. It will cause units to
be automatically started on installation, restarted on upgrade and stopped on removal for
every systemd user instance running on the system.

- Use of the dh_gconf command in override and hook targets now causes an error. The dh_gconf
command has been a no-op for years and was removed in debhelper 13.4.

- The dh sequencer will warn if the single-binary addon is implicitly activated to warn
maintainers of the pending compat 15 change in dh_auto_install.

Maintainers are urged to either explicitly activate the single-binary addon to preserve the
existing behaviour (e.g., by adding dh-sequence-single-binary to Build-Depends), or
explicitly passing --destdir to dh_auto_install if used and then passing --without single-
binary to dh (the latter to silence the warning).

The rationale for this change to avoid "surprises" when adding a second binary package later.
Previously, debhelper would silently change behaviour often resulting in empty binary
packages being uploaded to the archive by mistake. With the new behaviour, the single-binary
addon will detect the mismatch and warn the maintainer of what is about to happen.

v15 Diese Kompatibilitätsstufe ist immer noch für die Entwicklung offen. Verwenden Sie sie mit Vorsicht.

Changes from v14 are:

- The dh_auto_install tool no longer defaults to --destdir=debian/package for source packages
only producing a single binary. If this behaviour is wanted, the package should explicitly
activate the single-binary dh addon (e.g., by adding dh-sequence-single-binary to Build-
Depends) or pass --destdir to dh_auto_install.

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 Absätzen 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.

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.

Für jeden Befehl werden die benötigten Abhängigkeiten in den Handbuchseiten dokumentiert. Daneben wird
automatisch eine »substvar« erzeugt, die ${misc:Depends} genannt wird. Falls Sie eine Markierung in Ihre
debian/control-Datei schreiben, wird es sie zu den Abhängigkeiten expandieren, von denen Debhelper
findet, dass Sie sie benötigen.

Dies ist gänzlich unabhängig von dem vorgegebenen ${shlibs:Depends}, das durch dh_makeshlibs(1) erzeugt
wurde, und den durch dh_perl(1) erzeugten ${perl:Depends}. Sie können sich entscheiden, keines davon
benutzen, falls die Einschätzung von Debhelper nicht der Wirklichkeit entspricht.

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 Vezeichnis 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
Absatz 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
auf 1 gesetzt, um den Modus mit detailreicher Ausgabe zu aktivieren. Debhelper wird jeden von ihm
ausgeführten Befehl ausgeben. Außerdem wird die detailreiche Ausgabe von Bauprotokollen für einige
Bausysteme wie Autoconf aktiviert.

DH_QUIET
auf 1 gesetzt, um den detailarmen Modus zu aktivieren. Debhelper wird weder Befehle ausgeben, die das
Bausystem der Ursprungsautoren aufrufen, noch wird Dh ausgeben, 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 Buildd-Protokoll ziemlich
nutzlos. Falls DH_VERBOSE ebenfalls gesetzt ist, wird diese Einstellung ignoriert.

DH_COMPAT
gibt vorübergehend an, auf welcher Kompatibilitätsstufe Debhelper ausgeführt werden soll und setzt
dabei jeden Wert außer Kraft, der über Build-Depends in Debhelper-compat oder über die Datei
debian/compat angegeben wurde.

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 später werden diese Umgebungsvariablen zurückgesetzt, bevor das
Originalautoren-Bausystem 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_MAINT_BUILD_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 auf der Abschussliste stehenden Kompaitiblitä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, wenndie 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.

noautodbgsym, noddebs
Der offizielle Name ist autodbgsym. 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.

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

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

13.6ubuntu1                                        2022-02-07                                       debhelper(7)