Provided by: debhelper_11.1.6ubuntu2_all 
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 kennzeichnet, gehen alle Debhelper-Werkzeuge davon aus, dass sie
aus dem Wurzelverzeichnis eines entpackten Quellpakets ausgeführt werden. Dies ist deshalb so, weil sie
dann debian/control und debian/compat finden können, wenn nötig.
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_fixperms(1)
korrigiert Zugriffsrechte von Dateien in Bauverzeichnissen
dh_gconf(1)
installiert Standard-GConf-Dateien und registriert Schemen
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 Änderungsprotokolle (»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_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_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 aufgelistete Binärpaket
debian/foo benutzen wird, wenn es dort keine debian/package.foo-Datei gibt.
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, damit sie leicht zu lesen, zu verstehen
und zu ändern sind. Falls Sie Leistung und Komplexität vorziehen, können Sie die Datei ausführbar machen
und ein Programm schreiben, das das ausgibt, was auch immer für eine gegebene Situation geeignet ist.
Wenn Sie dies tun, wird die Ausgabe nicht weiter verarbeitet, um Platzhalter zu expandieren oder
Kommentare zu entfernen.
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.
This option is removed in compat 12.
-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.
--ignore=Datei
ignoriert die angegebene Datei. Dies ist sinnvoll, falls debian/ eine Debhelper-Konfigurationsdatei
enthält, auf die ein Debhelper-Befehl nicht einwirken soll. Beachten Sie, dass debian/compat,
debian/control und debian/changelog nicht ignoriert werden können, andererseits sollte es nie einen
Grund geben, diese Dateien zu ignorieren.
Falls die Originalautoren zum Beispiel ein debian/init liefern, von dem Sie nicht wünschen, dass
dh_installinit es installiert, benutzen Sie --ignore=debian/init
-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 \fElement\fR 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.
-DVerzeichnis, --sourcedirectory=Verzeichnis
geht davon aus, dass der Quellverzeichnisbaum des Originalpakets im angegebenen Verzeichnis, anstatt
auf der obersten Verzeichnisebene des Debian-Quellpaketverzeichnisbaums, liegt.
-B[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.
--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. Die
Kompatibilitätsstufe wird in der Datei debian/compat angegeben. Diese Datei muss vorhanden sein.
Schreiben Sie eine Zahl nach debian/compat, um Debhelper mitzuteilen, welche Kompatibilitätsstufe es
nutzen soll. Um beispielsweise den Modus V11 zu benutzen, geben Sie Folgendes ein:
% echo 11 > debian/compat
Ihr Paket wird außerdem eine Bauabhängigkeit mit Versionspflege auf eine Debhelper-Version benötigen, die
gleich (oder größer) als die ist, die von der Kompatibilitätsstufe Ihres Pakets verwandt wird. Daher
müssen Sie für Kompatibilitätsstufe 11 sicherstellen, dass debian/control Folgendes hat:
Build-Depends: debhelper (>= 11)
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 Änderungsprotokoll 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 Abfolgeerweiterung 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 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.
- 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 Abfolgesteuerung«
(--before, --after, etc.) akzeptieren. Bitte verwenden Sie stattdessen Aufhebungsziele.
- Der Befehl dh wird zur Verfolgung, welche Befehle ausgeführt wurden, nicht länger
Protokolldateien benutzen. Der Befehl dh verfolgt weiterhin, ob die »Bau«-Abfolge ausgeführt
wurde und überspringt sie in diesem Fall.
Die wichtigsten Auswirkungen davon sind:
- Hierdurch wird die Fehlersuche bei den Abfolgen 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-Abfolge 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-Abfolge ist nun standardmäßig aktiviert. Bitte übergeben Sie --without systemd an
dh, falls dies für ein angegebenes Paket nicht gewünscht wird.
v11 Dies ist der empfohlene Betriebsmodus.
Ä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-Abfolge 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.
Migration note: A bug in debhelper 11 up to 11.1.5 made dh_installinfo incorrectly ignore
--sourcedir.
- 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 werden nun versuchen, das »Hauptpaket«
für ein angegebenes Dokumentationspaket zu erraten (das Hauptpaket von Dokumentationspaket
wird z.B. Paket sein, falls letzteres existiert). Falls ein Hauptpaket gefunden wird, wird
die meiste Dokumentation standardmäßig in /usr/share/doc/main-pkg installiert, wie es durch
die Debian-Richtlinien §12.3 seit Version 3.9.7 empfohlen wird. Beachtenswerte Ausnahmen
enthalten die Copyright-Datei und die Changelog-Dateien.
Die Option --doc-main-package kann benutzt werden, wenn die automatische Erkennung
unzureichend ist.
- 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 Diese Kompatibilitätsstufe ist immer noch für die Entwicklung offen. Verwenden Sie sie mit Vorsicht.
Änderungen gegenüber v11 sind:
- 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.
- The dh_missing tool will now default to --list-missing.
- The dh_makeshlibs tool will now only pass libraries to dpkg-gensymbols(1) if the ELF binary
has a SONAME (containing ".so").
- The dh_compress tool no longer compresses examples (i.e. anything installed in
</usr/share/doc/package/examples>.)
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 in debian/compat außer Kraft.
DH_NO_ACT
auf 1 gesetzt, um Modus ohne Aktion zu aktivieren.
DH_OPTIONS
Alles in dieser Variable wird den Befehlszeilenargumenten aller Debhelper-Befehle vorangestellt.
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
If set, this adds the specified dh addons to be run in the appropriate places in the sequence of
commands. This is equivalent to specifying the addon to run with the --with flag in the debian/rules
file. Any --without calls specifying an addon in this environment variable will not be run.
This is intended to be used by downstreams or specific local configurations that require a debhelper
addon to be run during multiple builds without having to patch a large number of rules file. If at
all possible, this should be avoided in favor of a --with flag in the rules file.
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>
11.1.6ubuntu2 2018-05-10 debhelper(7)