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 wird benutzt, um 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. Dies bedeutet für Sie als Paketierer weniger Arbeit.
Außerdem heißt das zu einem gewissen Grad, dass diese Werkzeuge geändert werden können,
wenn sich die Debian-Richtlinie ändert und Pakete, die sie heranziehen, nur neu gebaut
werden müssen, um ihr zu entsprechen.

Eine typische debian/rules-Datei, die Debhelper benutzt, wird mehrere Debhelper-Befehle
hintereinander aufrufen oder dh(1) verwenden, 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 können das Paket dh-make
ausprobieren, das einen dh_make-Befehl enthält, der den Prozess teilweise automatisiert.
Für eine behutsamere Einführung enthält das Paket maint-guide ein Lernprogramm, wie Sie
Ihr erstes Paket unter Verwendung von Debhelper erstellen.

Wo das Werkzeug es nicht ausdrücklich anders kennzeichnet, gehen alle Debhelper-Werkzeuge
davon aus, dass sie aus dem Wurzelverzeichnis eines entpackten Quellpakets ausgeführt
werden. Dadurch können Sie dann, 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 Programms 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 feste 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 Datei »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 Einrichtungsverwaltungsskripte

       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ützende Dateien

       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 außer Kraft setzende 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)
           startet/stoppt oder startet Systemd-Unit-Dateien erneut

       dh_testdir(1)
           Verzeichnis vor dem Bauen des Debian-Pakets testen

       dh_testroot(1)
           stellt sicher, dass ein Paket mit der notwendigen Stufe von 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_gconf(1)
           installiert Standard-GConf-Dateien und registriert Schemen (missbilligt)

       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. Lesen Sie die Handbuchseiten
der einzelnen Befehle, um Einzelheiten über die Namen und Formate der Dateien zu erhalten,
die sie verwenden. Im Allgemeinen werden diese Dateien Dateien auflisten, auf die sie
einwirken, 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, einfache Ersetzungen in einigen
Debhelper-Konfigurationsdateien zu benutzen (insbesondere in Konfigurationsdateien für
dh_install(1)).

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 Zweifel ist die Variante DEB_HOST_* diejenige, die sowohl für natives als auch für
Bauen für andere Architekturen funktioniert.

Aus Leistungsgründen wird Debhelper versuchen, diese Namen aus der Umgebung
aufzulösen, bevor es Rat bei dpkg-architecture(1) sucht. Dies ist 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 die Umgebungsvariable NAME. Die Umgebungsvariable muss gesetzt sein (kann
aber auf eine leere Zeichenkette gesetzt sein).

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 (sie kann auf eine leere Zeichenkette gesetzt werden).

Ersetzungsbeschränkungen

Um Endlosschleifen und Ressourcenverschwendung zu vermeiden, wird Debhelper mit einer
Fehlermeldung stoppen, 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 benutzen, 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 bitte
Folgendes wissen:

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

• Auf Kompatibilitätsstufen über 13 unterliegt die Ausgabe Ersetzungen (siehe
"Ersetzungen in Debhelper-Konfigurationsdateien"), wenn das Werkzeug diese
unterstützt. Denken Sie daran, dass Sie vorsichtig sein müssen, 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 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 architekturunabhä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 zu verarbeiten auflisten.

--remaining-packages
wirkt sich nicht auf die Pakete aus, auf die sich dieser Debhelper-Befehl bereits
ausgewirkt hat (d.h. falls der Befehl im Debhelper-Protokoll des Pakets auftaucht).
Falls Sie zum Beispiel den Befehl mit speziellen Optionen für nur ein paar Binärakete
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, welches Paket Debhelper als »Hauptpaket« ansieht,
sprich das erste in debian/control aufgeführte und das, für das debian/foo-Dateien,
statt 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 Bündel von Optionen unterstützt, kommt er zum Tragen. Falls der Befehl (oder
irgend ein Teil eines Optionenbündels) den Befehl nicht unterstützt, 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-Ptogrammen
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 all die 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, anstatt auf der obersten Verzeichnisebene des Debian-
Quellpaketverzeichnisbaums, liegt.

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

Als 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 Bauen 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 maximale Stufe setzen, von der bekannt ist,
dass sie funktioniert oder auf die, von der Sie wünschen, dass sie unterstützt wird.

Bemerkenswerterweise ist das Setzen des Maximums auf 1 tatsächlich 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 ist in sehr seltenen Fällen nützlich, wenn das Paket mehrere Bauvorgänge mit
unterschiedlichen …FLAGS-Optionen benötigt. Ein konkretes Beispiel wäre die
Notwendigkeit der Änderung des Parameters -O in CFLAGS beim zweiten Bauen:

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, da dh_auto_configure(1) den
zwischengespeicherten Wert von CFLAGS, der durch dh(1) gesetzt wurde, benutzen.

Diese Option ist nur mit debhelper (>= 12.7~) 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 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 ordentlich und gut entworfen wie nötig zu halten und weil
sein Autor mehr Erfahrung gewinnt. Um zu verhindern, dass solche wesentlichen Änderungen
existierende Pakete beschädigen, wurde das Konzept der Debhelper-Kompatibilitätsstufen
eingeführt. Sie müssen Debhelper mitteilen, welche Kompatibilitätsstufe es nutzen soll und
es ä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 v12 zu benutzen, stellen Sie sicher, dass debian/control Folgendes enthält:

Build-Depends: debhelper-compat (>= 12)

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
Punktverö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 und das aktuelle Debhelper unterstützt dies immer noch aufgrund der
Rückwärtskompatibilität, 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 versionierte
Bauabhängigkeit zum Debhelper-Paket benötigen, die gleich der (oder größer als die)
Kompatibilitätsstufe ist, die Ihr Paket verwendet. Daher sollten Sie, falls Sie die
Kompatibilitätsstufe 12 in debian/compat angeben, sicherstellen, dass debian/control
Folgendes enthält:

Build-Depends: debhelper (>= 12~)

Wenn nicht anders angegeben, geht sämtliche Debhelper-Dokumentation davon aus, dass Sie
die aktuellste Kompatibilitätsstufe nutzen und in den meisten Fällen wird nicht angezeigt,
wenn sich dieses Verhalten von einer älteren Kompatibilitätsstufe unterscheidet. Wenn 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:

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

Dieser Modus ist missbilligt.

v6 Änderungen gegenüber v5 sind:

- Befehle, die Fragmente von Betreuerskripten erzeugen, werden die Fragmente für
die prerm- und postrm-Skripte in umgekehrter Reiherfolge anordnen.

- dh_installwm wird einen untergeordneten Handbuchseiten-Link für
x-window-manager.1.gz installieren. falls es die Handbuchseite in
usr/share/man/man1 im Bauverzeichnis des Pakets entdeckt.

- dh_builddeb löschte vorher nichts, was auf DH_ALWAYS_EXCLUDE passte, aber es
wurde auf eine Liste von Dingen gesetzt, die ausgeschlossen werden sollen, wie
CVS:.svn:.git. Nun tut es dies.

- dh_installman erlaubt das Überschreiben existierender Handbuchseiten im
Bauverzeichnis des Pakets. In vorhergehenden Kompatibilitätsstufen lehnte es
lautlos ab, dies zu tun.

Dieser Modus ist missbilligt.

v7 Änderungen gegenüber v6 sind:

- dh_install wird darauf zurückgreifen, in debian/tmp nach Dateien zu suchen,
falls es sie nicht im aktuellen Verzeichnis findet (oder wo auch immer Sie es
unter Benutzung von --sourcedir vorgeben). Dies ermöglicht dh_install mit
dh_auto_install zusammenzuarbeiten, das nach debian/tmp installiert, ohne
irgendwelche besonderen Parameter zu benötigen.

- dh_clean wird debian/clean lesen und die dort aufgeführten Dateien löschen.

- <dh_clean> wird die *-stamp-Dateien der obersten Ebene löschen.

- dh_installchangelogs wird abschätzen, in welcher Datei das Changelog der
Originalautoren liegt, falls keines angegeben wurde.

Dieser Modus ist missbilligt.

v8 Änderungen gegenüber v7 sind:

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

- dh_makeshlibs wird dpkg-gensymbols auf allen gemeinsam benutzten Bibliotheken
ausführen, für die es Shlib-Dateien erzeugt. Daher kann -X verwandt werden, um
Bibliotheken auszuschließen. Außerdem würden dpkg-gensymbols Bibliotheken an
unüblichen Orten übergeben, die es ansonsten nicht verarbeiten würde. Solche
Verhaltensänderung kann den Bau einiger Pakete zum Scheitern bringen.

- dh erfordert, dass die auszuführende Sequenz als erster Parameter angegeben
wird und sämtliche Schalter danach kommen. »dh $@ --foo« nicht »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 Zielen in debian/rules. Daher
wird »dh binary« alle »build«-, »build-arch«-, »build-indep«-, »install«-Ziele
etc. ausführen, die in dieser 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 installierte Größe von
»-dbg«-Paketen zu verringern.

- dh_auto_configure enthält nicht den 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.

v10 Änderungen gegenüber v9 sind:

- dh_installinit wird nicht mehr eine Datei namens debian/Paket 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 es 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.

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

- Der Befehl dh wird zur Verfolgung, welche Befehle ausgeführt wurden, nicht
länger Protokolldateien benutzen. Der Befehl dh verfolgt weiterhin, ob die
»Bau«-Sequenz ausgeführt wurde und überspringt sie in diesem Fall.

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 Pferdefuss hier liegt darin, dass dh_* nun nur noch nachverfolgt, was
in einem einzelnen außer Kraft setzenden Ziel geschieht. Wenn alle Aufrufe
eines angegebenen dh_cmd-Befehls im selben außer Kraft setzenden 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 außer Kraft setzenden
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. Dateinamen in
Anführungszeichen setzen).

- Voreinstellung für den Befehl dh_installinit ist nun --restart-after-upgrade.
Verwenden Sie bitte für Pakete, die das vorhergehende Verhalten erfordern,
--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
gewünscht wird.

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

- 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 keine Berichte zu Problemen gab, die dieser Fehler in
circa fünf Jahren verursachte, wurde er entfernt anstatt behoben.

v11 Von diesem Modus wird abgeraten.

Von der Kompatibilitätsstufe 11 wird für neue Pakete abgeraten, da sie unter
Funktionalitätswechselwirkungen zwischen dh_installinit unddh_installsystemd leidet,
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 außer
Kraft setzendes 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 nun 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
Fehler in Befehlen offenlegen, die nicht in Debhelper enthalten sind.

- Die Hilfsprogramme dh_installdocs, dh_installexamples, dh_installinfo und
dh_installman geben nun Fehlermeldungen aus, 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, wobei obige
Werkzeuge stillschweigend fehlschlagende Suchen erlauben, wobei die Suchmuster
zur Angabe von Dokumentation benutzt werden.

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

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

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

- Die Umgebungsvariable PERL_USE_UNSAFE_INC wird nicht mehr durch dh oder eins
der dh_auto_*-Werkzeuge gesetzt. Sie wurde vorübergehend als Behelfslösung
gesetzt, um zu verhindern, dass das gleichzeitige Bauen vieler Pakete
scheitert.

Beachten Sie, dass dieses Element eventuell hinfällig wird, da die
Ursprungsautoren beabsichtigen, die Unterstützung für die Umgebungsvariable
PERL_USE_UNSAFE_INC einzustellen. Wenn Perl die Unterstützung dafür einstellt,
wird diese Variable nachträglich auch aus bestehenden Kompatibilitätsstufen
entfernt.

- Das Hilfsprogramm dh_makeshlibs wird nun mit einer Fehlermeldung beendet,
falls Objdump einen Rückgabewert ungleich Null von der Auswertung einer
übergebenen Datei zurückgibt.

- Die Werkzeuge dh_installdocs und dh_installexamples installieren nun
möglicherweise die meiste Dokumentation in einem anderen Pfad, 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 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 Pakete
-doc-Pakete 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. D.h. 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 schauen 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 Dies ist der empfohlene Betriebsmodus.

Änderungen gegenüber v11 sind:

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

Falls ein 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-Funktionen (und ähnlichen) 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 nicht mehr die Konfiguration für
das Init-System Upstart. Stattdessen bricht es das Bauen ab, wenn es eine alte
Upstart-Konfigurationsdatei findet. Der Fehler ist dort, um den Paketbetreuer
daran zu erinnern, dass er sicherstellt, die mit vorherigen Versionen des
Pakets mitgelieferten Conffiles (falls vorhanden) sauber zu entfernen.

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

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

- Das Werkzeug dh_makeshlibs wird nun 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. Sie werden nun mit einem Fehler scheitern. Falls Sie diese Befehl
überspringen wollen, fügen Sie bitte ein leeres außer Kraft setzendes 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 daher auf die Voreinstellung des Bausystems, die
/usr/libexec sein sollte (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, z.B. wie im folgenden Beispiel:

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

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

- Das Werkzeug dh_installdeb installiert nicht mehr die vom Paketbetreuer
bereitgestellte conffiles-Datei. Die Datei war seit Kompatibilitätsstufe 3
meist überflüssig, als dh_installdeb anfing, die resultierende
conffiles-Steuerdatei automatisch selbst zu berechnen.

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

Falls Sie etwas haben, was dh_installinit außer Kraft setzt (z.B. um es mit
--no-start aufzurufen), dann werden Sie wahrscheinlich auch etwas 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 nun
standardmäßig die Variable DH_GOLANG_EXCLUDES für die Quelleninstallation in
-dev-Paketen und 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 wurde nun entfernt. Bitte verwenden Sie
stattdessen das Drittanbieterbausystem pybuild.

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

Änderungen gegenüber v12 sind:

- Das Bausystem meson+ninja benutzt nun meson test anstelle von ninja 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 sich
widersprechende Definitionen einer Handbuchseite entdeckt. Dies geschieht
normalerweise, falls 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. HOME und XDG_RUNTIME_DIR sind jeweils
auf ein separates, schreibbares Verzeichnis gesetzt. Die restlichen
Umgebungsvariablen werden geleert.

- Der Befehl dh wird nun einen Fehler ausgeben, falls ein außer Kraft setzendes
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 kann zu
einer nicht fatalen Warnung zurück geändert werden, 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 außer Kraft setzenden 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.

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

- Viele dh_*-Werkzeuge unterstützen nun 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 erfolgt als Teil der
Funktionen filearray und filedoublearray.

- Der Befehlssequenzer dh wird nun alle Hooks und außer Kraft setzenden 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 maßgebliche 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.

- The cmake buildsystem now passes -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON to
cmake(1) to speed up automatic installation process. If for some reason you
need previous behavior, override the flag:

dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...

ANMERKUNGEN

Unterstützung mehrerer Binärpakete
Falls Ihr Quellpaket mehr als ein Binärpaket erzeugt, werden Debhelper-Programme
standardmäßig bei der Ausführung 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 vornehmen.

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 hinzufügen, an
die der Kode hinzugefügt werden soll. #DEBHELPER# wird bei der Ausführung durch
irgendeinen automatisch erzeugten Kode ersetzt.

Falls ein Skript überhaupt noch 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 dies 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 beschrieben, dies zu tun (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 davon abhängen, wie
Debhelper Dinge tut, 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 auswählen, keines davon zu 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, falls Sie -P verwenden, dass
die Debhelper-Programme nur auf ein einzelnes Paket auf einmal einwirken kann. Falls Sie
also ein Paket haben, das mehrere Binärpakete baut, müssen Sie außerdem 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, indem keine Dokumentation in ein Udeb
installiert wird und indem preinst-, postrm-, prerm- und config-Skripte etc. übersprungen
werden.

UMGEBUNGSVARIABLEN

Die folgenden Umgebungsvariablen können das Verhalten von Debhelper beeinflussen. Es ist
wichtig, darauf hinzuweisen, dass dies tatsächlich 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
sollte 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
irgendwelchen 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, auf den die Variable gesetzt ist, den -X-Optionen
aller Befehle hinzu, die die Option -X unterstützen. Außerdem wird dh_builddeb für
alles, das dem Wert in Ihrem Paketbaubaum entspricht, rm -rf ausführen.

Dies kann nützlich sein, falls Sie aus einem CVS-Quellverzeichnisbaum bauen. In diesem
Fall verhindert das Setzen von DH_ALWAYS_EXCLUDE=CVS, dass irgendwelche CVS-
Verzeichnisse sich 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 Sequenzen von Befehlen 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 eine Debhelper-Erweiterung benötigen, während mehrfachem
Bauen ausgeführt werden, ohne ein große Anzahl von Dateien ausbessern zu müssen. 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 dieselben Farbeinstellungen für
Dpkg und Debhelper benutzen wollen. In dem unwahrscheinlichen Fall, dass Sie für
Debhelper andere Farbeinstellungen möchten, können Sie DH_COLORS statt oder zusätzlich
zu DPKG_COLORS verwenden.

NO_COLOR
Falls nicht explizit um Farbe gebeten wurde (z.B. sowohl DH_COLORS als auch
DPKG_COLORS sind nicht gesetzt), führt das Vorliegen 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 die Funktionalität
von dpkg-buildflags(1), um dies zu tun (z.B. DEB_BUILD_MAINT_OPTIONS=hardening=all
oder DEB_CPPFLAGS_MAINT_APPEND=-DCUSTOM_MACRO=true), anstatt die konkrete Variable
direkt zu setzen.

HOME, XDG_*
In Kompatibilitätsstufe 13 und neuer werden diese Umgebungsvariable zurückgesetzt,
bevor das Baussystem der Ursprungsautoren über die dh_auto_*-Hilfsprogramme aufgerufen
wird. Die Variablen HOME und XDG_RUNTIME_DIR werden auf ein beschreibbares Verzeichnis
gesetzt. Die verbleibenden Variablen werden geleert.

Die Verzeichnisse werden leer erzeugt, sie werden allerdings zwischen den
dh_auto_*-Aufrufen weiter benutzt. Jeglicher Inhalt wird weiter bestehen, bis er
explizit gelöscht oder dh_clean aufgerufen wird.

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>