Provided by: debhelper_13.9.1ubuntu1_all 
NAME
debhelper - die Debhelper-Werkzeugsammlung
ÜBERSICHT
dh_* [-v] [-a] [-i] [--no-act] [-pPaket] [-NPaket] [-Ptemporäres_Verzeichnis]
BESCHREIBUNG
Debhelper ist dafür da, Ihnen beim Bau eines Debian-Pakets zu helfen. Die Philosophie
hinter Debhelper ist, eine kleine, einfach und leicht verständliche Werkzeugsammlung
bereitzustellen, die in debian/rules verwandt wird, um verschiedene geläufige Aspekte der
Paketerstellung zu automatisieren und Ihnen auf diese Weise Arbeit abzunehmen. Darüber
hinaus können diese Werkzeuge bis zu einem gewissen Grad an etwaige Änderungen an der
Debian-Richtlinie angepasst werden, sodass die Pakete, welche die Werkzeuge verwenden,
lediglich neu erzeugt werden müssen, um der geänderten Richtlinie zu entsprechen.
Eine typische debian/rules-Datei, die Debhelper benutzt, ruft mehrere Debhelper-Befehle
hintereinander auf oder verwendet dh(1), um diesen Prozess zu automatisieren. Beispiele
für Regeldateien, die Debhelper einsetzen, liegen in /usr/share/doc/debhelper/examples/.
Um ein neues Debian-Paket unter Benutzung von Debhelper zu erstellen, können Sie einfach
eine Beispielregeldatei kopieren und manuell bearbeiten. Oder Sie probieren das Paket dh-
make aus; dieses enthält einendh_make-Befehl, welcher den Prozess teilweise automatisiert.
Für eine behutsamere Einführung enthält das Paket ucmaint-guide ein Lernprogramm, mit dem
Sie Ihr erstes Paket unter mit Hilfe von Debhelper erstellen.
Solange nichts anderes angegeben wird, gehen alle Debhelper-Werkzeuge davon aus, dass sie
aus dem Wurzelverzeichnis eines entpackten Quellpakets ausgeführt werden. Dadurch können
sie, wenn notwendig, Dateien wie debian/control finden.
DEBHELPER-BEFEHLE
Hier ist die Liste der Debhelper-Befehle, die Sie benutzen können. Zusätzliche
Dokumentation finden Sie in deren Handbuchseiten.
dh_auto_build(1)
baut ein Paket automatisch
dh_auto_clean(1)
räumt nach dem Bauen automatisch auf
dh_auto_configure(1)
konfiguriert das Paket automatisch vor dem Bauen.
dh_auto_install(1)
führt »make install« oder Ähnliches aus
dh_auto_test(1)
führt automatisch die Test-Suites eines Pakets aus
dh_bugfiles(1)
installiert Dateien zur Anpassung von Fehlerberichten in Bauverzeichnisse von Paketen.
dh_builddeb(1)
baut binäre Debian-Pakete
dh_clean(1)
räumt die Bauverzeichnisse des Pakets auf
dh_compress(1)
komprimiert Dateien und korrigiert symbolische Links in Bauverzeichnissen von Paketen
dh_dwz(1)
optimiert DWARF-Fehlersuchinformationen in ELF-Binärdateien über dwz
dh_fixperms(1)
korrigiert Zugriffsrechte von Dateien in Bauverzeichnissen
dh_gencontrol(1)
erzeugt und installiert die Steuerdatei »control«
dh_icons(1)
aktualisiert die Zwischenspeicher von Freedesktop-Symbolen
dh_install(1)
installiert Dateien in Bauverzeichnisse von Paketen
dh_installcatalogs(1)
installiert und registriert SGML-Kataloge
dh_installchangelogs(1)
installiert Changelogs in die Paketbauverzeichnisse
dh_installcron(1)
installiert Cron-Skripte in etc/cron.*
dh_installdeb(1)
installiert Dateien in das Verzeichnis DEBIAN.
dh_installdebconf(1)
installiert Dateien, die von Debconf im Paketbauverzeichnis benutzt werden
dh_installdirs(1)
erstellt Unterverzeichnisse in den Paketbauverzeichnissen
dh_installdocs(1)
installiert Dokumentation in Paketbauverzeichnisse
dh_installemacsen(1)
registriert ein Emacs-Add-on-Paket
dh_installexamples(1)
installiert Beispieldateien in die Paketbauverzeichnisse.
dh_installifupdown(1)
installiert »if-up«- und »if-down«-Hooks.
dh_installinfo(1)
installiert Info-Dateien
dh_installinit(1)
installiert Dienstinitialisierungsdateien in Paketbauverzeichnisse
dh_installinitramfs(1)
installiert Initramfs-Hooks und richtet Maintscripts ein
dh_installlogcheck(1)
installiert Regeldateien zur Protokollprüfung in etc/logcheck/
dh_installlogrotate(1)
installiert Konfigurationsdateien von Logrotate
dh_installman(1)
installiert Handbuchseiten in Paketbauverzeichnisse
dh_installmenu(1)
installiert Debian-Menü-Dateien in Paketbauverzeichnisse
dh_installmime(1)
installiert MIME-Dateien in Paketbauverzeichnisse
dh_installmodules(1)
registriert Kernel-Module
dh_installpam(1)
installiert PAM-Unterstützungsdateien
dh_installppp(1)
installiert PPP-ip-up- und -ip-down-Dateien
dh_installudev(1)
installiert udev-Regeldateien
dh_installwm(1)
registriert einen Fenstermanager
dh_installxfonts(1)
registriert X-Schriften
dh_link(1)
erzeugt symbolische Links in Paketbauverzeichnisse
dh_lintian(1)
installiert Override-Dateien für Lintian in Paketbauverzeichnisse
dh_listpackages(1)
listet Binärpakete auf, auf die Dephelper einwirken wird
dh_makeshlibs(1)
erstellt automatisch die Shlibs-Datei und ruft dpkg-gensymbols auf
dh_md5sums(1)
erzeugt die Datei DEBIAN/md5sums
dh_movefiles(1)
verschiebt Dateien aus debian/tmp in Unterpakete
dh_perl(1)
berechnet Perl-Abhängigkeiten und räumt nach MakeMaker auf
dh_prep(1)
führt Säuberungsaktionen als Vorbereitung des Baus von Binärpaketen durch
dh_shlibdeps(1)
berechnet Abhängigkeiten gemeinsam benutzter Bibliotheken
dh_strip(1)
entfernt Symbole aus Programmen, gemeinsam benutzten Bibliotheken und einigen
statischen Bibliotheken
dh_systemd_enable(1)
aktiviert/deaktiviert Systemd-Unit-Dateien
dh_systemd_start(1)
Start/Stopp/Neustart von Systemd-Unit-Dateien
dh_testdir(1)
Verzeichnis vor dem Bauen des Debian-Pakets testen
dh_testroot(1)
stellt sicher, dass ein Paket mit dem notwendigen Umfang an Root-Rechten gebaut wird.
dh_usrlocal(1)
migriert usr/local-Verzeichnisse zu Betreuerskripten
Missbilligte Befehle
Ein paar Debhelper-Befehle sind veraltet und sollten nicht benutzt werden.
dh_installmanpages(1)
Handbuchseiteninstallationsprogramm im alten Stil (veraltet)
Weitere Befehle
Falls ein Programmname mit dh_ beginnt und das Programm nicht auf obiger Liste steht, dann
ist es nicht Teil des Debhelper-Pakets, sollte aber trotzdem wie die anderen auf dieser
Seite beschriebenen Programme funktionieren.
DEBHELPER-KONFIGURATIONSDATEIEN
Viele Debhelper-Befehle machen von den Dateien in debian/ Gebrauch, um zu steuern, was sie
tun. Neben den üblichen debian/changelog und debian/control, die in allen Paketen
enthalten sind (nicht nur in denen, die Debhelper benutzen), können einige zusätzliche
Dateien verwandt werden, um das Verhalten bestimmter Debhelper-Befehle zu konfigurieren.
Diese Dateien heißen üblicherweise debian/Paket.foo (wobei Paket natürlich durch das Paket
ersetzt wird, auf das es sich auswirkt).
dh_installdocs benutzt beispielsweise Dateien mit dem Namen debian/package.docs, um die
Dokumentationsdateien aufzulisten, die es installieren wird. Welche Dateien die einzelnen
Befehle heranziehen, ihre Namen und Formate, entnehmen Sie den entsprechenden
Handbuchseiten. Im Allgemeinen sind diese Dateien Listen von Dateien, die bearbeitet
werden, eine Datei pro Zeile. Einige Programme in Debhelper bedienen sich Paaren von
Dateien und Zielen oder etwas kompiziertere Formate.
Beachten Sie, dass Debhelper für das erste (oder einzige) in debian/control aufgeführte
Binärpaket debian/foo benutzen wird, wenn es keine debian/Paket.foo-Datei gibt. Oft ist es
jedoch eine gute Idee, das Präfix Paket. zu behalten, da es eindeutiger ist. Die
Hauptausnahme davon bilden Dateien, die Debhelper standardmäßig in jedem Binärpaket
installiert, wenn es kein Paketpräfix besitzt (wie debian/copyright oder
debian/changelog).
In einigen seltenen Fällen möchten Sie möglicherweise unterschiedliche Versionen dieser
Dateien für unterschiedliche Architekturen oder Betriebssysteme haben. Falls Dateien mit
den Namen debian/Paket.foo.ARCHITEKTUR oder debian/Paket.foo.BETRIEBSSYSTEM existieren,
wobei ARCHITEKTUR und BETRIEBSSYSTEM der Ausgabe von »dpkg-architecture
-qDEB_HOST_ARCH_OS« entsprechen, dann werden sie gegenüber anderen, allgemeineren Dateien,
bevorzugt.
Meist werden diese Konfigurationsdateien benutzt, um verschiedene Typen von Dateien
anzugeben – zu installierende Dokumentations- oder Beispieldateien, Dateien zum
Verschieben und so weiter. Wenn es in Fällen wie diesem zweckmäßig ist, können Sie die
Standardplatzhalterzeichen der Shell in den Dateien verwenden (?, * und
[..]-Zeichenklassen). Sie können außerdem Kommentare in diese Dateien einfügen; Zeilen,
die mit # beginnen, werden ignoriert.
Die Syntax dieser Dateien ist absichtlich sehr einfach gehalten, um sie leicht lesbar,
verständlich und änderbar zu machen.
Ersetzungen in Debhelper-Konfigurationsdateien
In Kompatibilitätsstufe 13 und neuer ist es möglich, in den debhelper-
Konfigurationsdateien einfache Ersetzungen für die folgenden Werkzeuge zu verwenden:
• dh_clean
• dh_install
• dh_installcatalogs
• dh_installdeb
• dh_installdirs
• dh_installdocs
• dh_installexamples
• dh_installinfo
• dh_installman
• dh_installvm
• dh_link
• dh_missing
• dh_ucf
Alle Ersetzungsvariablen haben die Form ${foo} und die Klammern sind Pflicht.
Variablennamen berücksichtigen Groß- und Kleinschreibung und bestehen aus alphanumerischen
Zeichen (a-zA-Z0-9), Bindestrichen (-), Unterstrichen (_) sowie Doppelpunkten (:). Das
erst Zeichen muss alphanumerisch sein.
Falls Sie ein Dollarzeichen benötigen, das kein Ersetzen auslösen kann, können Sie
entweder die ${Dollar}-Ersetzung oder die Sequenz ${} verwenden.
Die folgenden Expandierungen sind verfügbar:
DEB_HOST_*, DEB_BUILD_*, DEB_TARGET_*
expandiert auf den passenden dpkg-architecture(1)-Wert (ähnlich dpkg-architecture
-qVARIABLE_HIER).
Im Zweifelsfall ist die Variante DEB_HOST_* diejenige, die sowohl für natives Bauen
als auch für andere Architekturen funktioniert.
Aus Leistungsgründen versucht Debhelper, diese Namen aus der Umgebung aufzulösen,
bevor es Rat bei dpkg-architecture(1) sucht. Dies sei hauptsächlich der
Vollständigkeit halber erwähnt und hat in den meisten Fällen keine Bedeutung.
Dollar
expandiert auf ein einzelnes $-Symbol. Dieses Symbol wird niemals als Teil der
Ersetzungsvariable angesehen. Dies bedeutet:
# löst einen Fehler aus
${KEINE_DERARTIGE_MARKIERUNG}
# expandiert auf den genauen Wert »${KEINE_DERARTIGE_MARKIERUNG}«
${Dollar}{KEINE_DERARTIGE_MARKIERUNG}
Diese Variable entspricht der Sequenz ${} und beides kann synonym benutzt werden.
Newline, Space, Tab
expandiert auf einen einzelnen ASCII-Zeilenumbruch, Leerzeichen beziehungsweise
Tabulator.
Dies kann nützlich sein, wenn Sie ein Leerraumzeichen (z.B. Leerzeichen) einfügen
möchten, wo es andernfalls entfernt oder als Trennzeichen benutzt würde.
env:NAME
expandiert zur Umgebungsvariable NAME. Die Umgebungsvariable muss gesetzt sein (eine
leere Zeichenkette reicht).
Beachten Sie, dass alle Variablen auf einen definierten Wert expandiert werden müssen.
Wenn Debhelper beispielsweise ${env:FOO} sieht, wird es darauf bestehen, dass die
Umgebungsvariable FOO gesetzt ist (eine leere Zeichenkette reicht).
Ersetzungsbeschränkungen
Um Endlosschleifen und Ressourcenverschwendung zu vermeiden, bricht Debhelper mit einer
Fehlermeldung ab, falls der Text viele Ersetzungsvariablen (50) enthält oder sie über eine
bestimmte Größe expandieren (4096 Zeichen oder die dreifache Länge des Originaleingabe -
je nachdem, was größer ist).
Ausführbare Debhelper-Konfigurationsdateien
Falls Sie zusätzliche Flexibilität benötigen, unterstützen viele Debhelper-Werkzeuge (z.B.
dh_install(1)) die Ausführung einer Konfigurationsdatei als Skript.
Um diese Funktionalität zu nutzen, markieren Sie die Konfigurationsdatei einfach als
ausführbar (z.B. chmod +x debian/Paket.install) und das Werkzeug wird versuchen, es
auszuführen und die Ausgabe des Skripts zu verwenden. In vielen Fällen können Sie auch
dh-exec(1) als Interpreter der Konfigurationsdatei verwenden, um das Meiste der
Originalsyntax beizubehalten, obwohl Sie die zusätzliche Flexibilität wie gewünscht
erhalten.
Wenn Sie ausführbare Debhelper-Konfigurationsdateien verwenden, sollten Sie Folgendes
wissen:
• Die ausführbare Konfigurationsdatei muss erfolgreich enden (d.h. der Rückgabewert
sollte einen Erfolg anzeigen).
• Auf Kompatibilitätsstufen oberhalb von 13 unterliegt die Ausgabe Ersetzungen (siehe
"Ersetzungen in Debhelper-Konfigurationsdateien"), soweit das Werkzeug diese
unterstützt. Denken Sie daran, Vorsicht walten zu lassen, falls Ihr Generator auch
Ersetzungen bereitstellt, da dies zu unnötiger Verwirrung führen kann.
Andernfalls wird die Ausgabe exakt so benutzt, wie sie ist. Insbesondere wird
Debhelper Platzhalter nicht expandieren oder Kommentare und Leerzeichen aus der
Ausgabe entfernen.
Falls Sie das Paket auf einem Dateisystem bauen, auf dem Sie das Ausführungsbit nicht
deaktivieren können, können Sie dh-exec(1) und sein Skript strip-output verwenden.
GEMEINSAM BENUTZTE DEBHELPER-OPTIONEN
Die folgenden Befehlszeilenoptionen werden von allen Debhelper-Programmen unterstützt.
-v, --verbose
Detailreicher Modus: zeigt alle Befehle, die das Paketbauverzeichnis ändern
--no-act
tut nicht wirklich etwas. Falls es zusammen mit -v benutzt wird, wird als Ergebnis
ausgegeben, was der Befehl getan hätte.
-a, --arch
wirkt sich auf architekturabhängige Pakete aus, die für die Architektur DEB_HOST_ARCH
gebaut werden sollen.
-i, --indep
wirkt sich auf alle architektur-unabhängigen Pakete aus.
-pPaket, --package=Paket
wirkt sich auf das Paket mit Namen Paket aus. Diese Option kann mehrfach angegeben
werden, damit Debhelper mit einer Zusammenstellung von Paketen arbeitet.
-s, --same-arch
missbilligter Alias von -a.
Die Option wurde in Kompatibilitätsstufe 12 entfernt.
-NPaket, --no-package=Paket
verhindert Auswirkungen auf das angegebene Paket, sogar wenn die Optionen -a, -i oder
-p das Paket als ein zu verarbeitendes auflisten.
--remaining-packages
wirkt sich nicht auf die Pakete aus, die dieser Debhelper-Befehl bereits durchlaufen
hat (d.h. falls der Befehl im Debhelper-Protokoll des Pakets auftaucht). Falls Sie zum
Beispiel den Befehl nur bei einigen Binäraketen mit speziellen Optionen aufrufen
müssen, geben Sie diese Option beim letzten Aufruf des Befehls an, um die restlichen
Pakete mit Standardeinstellungen zu verarbeiten.
-Ptemporäres_Verzeichnis, --tmpdir=temporäres_Verzeichnis
benutzt temporäres_Verzeichnis als Bauverzeichnis des Pakets. Voreinstellung ist
debian/Paket.
--mainpackage=Paket
Diese selten benutzte Option ändert das Paket, welches Paket Debhelper als
»Hauptpaket« ansieht, sprich als das Paket, welches zuerst in debian/control
aufgeführt wird und für das die debian/foo-Dateien anstelle der üblichen
debian/Paket.foo-Dateien verwandt werden können.
-O=Option|Bündel
Dies wird von dh(1) verwandt, wenn benutzerdefinierte Optionen an alle von ihm
ausgeführten Befehle weitergereicht werden. Falls der Befehl die angegebene Option
oder das ganze Bündel von Optionen unterstützt,kommt er zum Tragen. Falls nicht, wird
er ignoriert.
HÄUFIGE DEBHELPER-OPTIONEN
Die folgende Befehlszeile wird von einigen Debhelper-Programmen unterstützt. Eine
vollständige Erklärung, was jede Option tut, finden Sie in den Handbuchseiten jedes
einzelnen Programms.
-n verändert keine postinst-, postrm- etc. Skripte
-XElement, --exclude=Element
schließt ein Element von der Verarbeitung aus. Diese Option kann mehrfach benutzt
werden, um mehr als nur eins auszuschließen. Das <Element> ist üblicherweise Teil
eines Dateinamens und jede Datei, die den angegebenen Text enthält, wird
ausgeschlossen.
-A, --all
bewirkt, dass Dateien oder andere Elemente, die auf der Befehlszeile angegeben wurden,
sich in ALLEN entsprechenden Paketen auswirken, nicht nur im ersten.
BAUSYSTEMOPTIONEN
Die folgenden Befehlszeilenoptionen werden von allen dh_auto_*-Debhelper-Programmen
unterstützt. Diese Programme unterstützen eine Vielzahl von Bausystemen und bestimmen
normalerweise heuristisch, welches benutzt werden soll und wie es verwendet wird. Sie
können diese Befehlszeilenoptionen nutzen, um das Standardverhalten zu ändern.
Typischerweise werden sie an dh(1) übergeben, das sie dann an alle dh_auto_*-Programme
übergibt.
-SBausystem, --buildsystem=Bausystem
erzwingt die Benutzung des angegebenen Bausystems, anstatt zu versuchen, automatisch
eins auszuwählen, das für das Paket geeignet sein könnte.
übergibt none als Bausystem, um automatisches Auswählen zu deaktivieren.
-DVerzeichnis, --sourcedir=Verzeichnis, --sourcedirectory=Verzeichnis
geht davon aus, dass der Quellverzeichnisbaum des Originalpakets im angegebenen
Verzeichnis statt auf der obersten Verzeichnisebene des Debian-
Quellpaketverzeichnisbaums liegt.
Warnung: Für die --sourcedir-Variante gibt es aus historischen Gründen eine ähnlich
benannte Option in dh_install und dh_missing (etc.). Obwohl ihre Namen identisch sind,
dienen sie völlig unterschiedlichen Zwecken, somit können in einigen Fällen Fehler
auftreten, wenn diese Variante an dh übergeben wird (und dieses sie seinerseits an
alle anderen Werkzeuge weitergibt).
-B[Verzeichnis], --builddir[=Verzeichnis], --builddirectory=[Verzeichnis]
aktiviert das Bauen aus dem Quelltext und benutzt das angegebene Verzeichnis] als
Bauverzeichnis. Falls der Parameter Verzeichnis] weggelassen wurde, wird ein
Vorgabebauverzeichnis ausgewählt.
Falls diese Option nicht angegeben ist, wird standardmäßig in der Quelle gebaut, falls
das Bausystem nicht das Bauen außerhalb des Quellverzeichnisbaums erfordert oder
bevorzugt. In einem solchen Fall wird das Standardbauverzeichnis benutzt, selbst wenn
--builddirectory angegeben wurde.
Falls das Bausystem das Bauen außerhalb des Quellverzeichnisbaums bevorzugt, aber das
Bauen innerhalb der Quelle immer noch erlaubt, kann Letzteres wieder aktiviert werden,
indem ein Bauverzeichnispfad übergeben wird, der dem Quellverzeichnispfad entspricht.
--parallel, --no-parallel
prüft, ob parallel gebaut werden soll, falls das zugrundeliegende Bausystem dies
unterstützt. Die Anzahl paralleler Aufgaben wird zur Bauzeit durch die
Umgebungsvariable DEB_BUILD_OPTIONS ("Debian-Richtlinie, Abschnitt 4.9.1") gesteuert,
Sie könnte außerdem Gegenstand einer bausystemspezifischen Begrenzung sein.
Falls keine der Optionen angegeben wurde, ist die Voreinstellung von Debhelper derzeit
--parallel in Kompatibilitätsversion 10 (oder höher) und andernfalls --no-parallel.
Zwecks Optimierung wird dh versuchen, die Übergabe dieser Optionen an Unterprozesse zu
vermeiden, falls sie unnötig sind und als einzige Optionen übergeben werden. Dies
geschieht insbesondere dann, wenn DEB_BUILD_OPTIONS keinen parallel-Parameter hat
(oder dessen Wert 1 ist).
--max-parallel=Maximum
Diese Option impliziert --parallel und erlaubt die weitere Begrenzung der Anzahl von
Aufgaben, die bei einem parallelen Bau benutzt werden können. Falls bekannt ist, dass
das Bauen des Pakets nur mit einer bestimmten Stufe der Gleichzeitigkeit funktioniert,
können Sie diese auf die höchste Stufe setzen, von der bekannt ist, dass sie
funktioniert oder auf die, von der Sie wünschen, dass sie unterstützt wird.
Übrigens bewirkt das Setzen des Maximums auf 1 dasselbe wie die Verwendung von
--no-parallel.
--reload-all-buildenv-variables
By default, dh(1) will compute several environment variables (e.g. by using
dpkg-buildflags(1)) and cache them to avoid having all dh_auto_* tool recompute them.
Wenn diese Option übergeben wird, wird das konkrete dh_auto_*-Werkzeug den
Zwischenspeicher von dh(1) ignorieren und das neue Erzeugen dieser Variablen auslösen.
Dies hilft in den sehr seltenen Fällen, in denen das Paket mehrere Bauvorgänge mit
unterschiedlichen …FLAGS-Optionen benötigt. Ein konkretes Beispiel wäre die
Notwendigkeit, den Parameter -O in CFLAGS beim zweiten Bauen abzuändern:
export DEB_CFLAGS_MAINT_APPEND=-O3
%:
dh $@
override_dh_auto_configure:
dh_auto_configure -Bbuild-deb ...
DEB_CFLAGS_MAINT_APPEND=-Os dh_auto_configure \
--reload-all-buildenv-variables -Bbuild-udeb ...
Ohne --reload-all-buildenv-variables im zweiten Aufruf von dh_auto_configure(1) würde
die Änderung in DEB_CFLAGS_MAINT_APPEND ignoriert werden, da dh_auto_configure(1) den
von durch dh(1) zwischengespeicherten CFLAGS-Wert benutzen würde.
Diese Option ist mit debhelper (>= 12.7~) nur verfügbar, wenn das Paket
Kompatibilitätsstufe 9 oder neuer verwendet.
--list, -l
listet alle Bausysteme auf, die auf diesem System von Debhelper unterstützt werden.
Diese Liste enthält sowohl Standardbausysteme als auch Bausysteme Dritter (als solche
gekennzeichnet). Außerdem zeigt es, welches Bausystem automatisch ausgewählt werden
würde oder welches durch die Option --buildsystem manuell angegeben wird.
KOMPATIBILITÄTSSTUFEN
Von Zeit zu Zeit müssen wesentliche, nicht rückwärtskompatible Änderungen an Debhelper
vorgenommen werden, um es so sauber und übersichtlich wie möglich zu halten, denn die
Bedürfnisse ändern sich bzw. sein Autor sammelt mehr Erfahrung. Um zu verhindern, dass
solche wesentlichen Änderungen existierende Pakete beschädigen, ist das Konzept der
Debhelper-Kompatibilitätsstufen eingeführt worden. Sie müssen Debhelper mitteilen, welche
Kompatibilitätsstufe es nutzen soll und sie ändert sein Verhalten auf verschiedene Arten.
Im aktuellen Debhelper können Sie die Kompatibilitätsstufe in debian/control angeben,
indem Sie ein Build-Depends für das Paket Debhelper-Compat hinzufügen. Um beispielsweise
den Modus v13 zu benutzen, stellen Sie sicher, dass debian/control Folgendes enthält:
Build-Depends: debhelper-compat (= 13)
Dies dient auch als eine geeignete versionierte Bauabhängigkeit zu einer ausreichenden
Version des Debhelper-Pakets, so dass Sie keine separate versionierte Bauabhängigkeit zum
Debhelper-Paket angeben müssen, es sei denn, Sie benötigen eine besondere
Zwischenveröffentlichung von Debhelper (wie für die Veröffentlichung einer neuen
Funktionalität oder einer Fehlerbehebung innerhalb einer Kompatibilitätsstufe).
Note that debhelper does not provide debhelper-compat for experimental or beta
compatibility levels; packages experimenting with those compatibility levels should use
debian/compat (or, if only for selected commands, DH_COMPAT).
Prior versions of debhelper required specifying the compatibility level in the file
debian/compat, and current debhelper still supports this for backward compatibility. To
use this method, the debian/compat file should contain the compatibility level as a single
number, and no other content. If you specify the compatibility level by this method, your
package will also need a versioned build dependency on a version of the debhelper package
equal to (or greater than) the compatibility level your package uses. So, if you specify
compatibility level 13 in debian/compat, ensure debian/control has:
Build-Depends: debhelper (>= 13~)
Note that you must use either the build-dependency on debhelper-compat or the
debian/compat file. Whenever possible, the debhelper-compat build-dependency is
recommended.
If needed be, the DH_COMPAT environment variable can be used to override the compat level
for a given command. The feature is mostly useful for either temporarily upgrading a few
commands to a new compat level or keeping a few commands on a lower compat level. The
feature is best used sparingly as it effectively introduces special-cases into the
debian/rules file that may be surprising to maintainers or reviewers (or, in the long
term, to yourself).
Wenn nicht anders angegeben, geht sämtliche Debhelper-Dokumentation davon aus, dass Sie
die aktuellste Kompatibilitätsstufe nutzen, und weist in den meisten Fällen nicht darauf
hin, wenn sich dieses Verhalten von einer älteren Kompatibilitätsstufe unterscheidet.
Sollten Sie also nicht die aktuellste Kompatibilitätsstufe benutzen, ist es eine gute
Idee, folgende Hinweise zu den Unterschieden gegenüber älteren Kompatibilitätsstufen zu
lesen.
Unterstützte Kompatibilitätsstufen
The list of supported compatibility levels and the related upgrade check list has moved to
debhelper-compat-upgrade-checklist(7).
ANMERKUNGEN
Unterstützung mehrerer Binärpakete
Falls Ihr Quellpaket mehr als ein Binärpaket erzeugt, werden die Debhelper-Programme
standardmäßig auf alle Paketen einwirken. Falls es vorkommt, dass Ihr Quellpaket ein
architekturabhängiges Paket und ein anderes architekturunabhängiges Paket erzeugt, ist
dies nicht das korrekte Verhalten, da Sie die architekturabhängigen Pakete im
debian/rules-Ziel »binary-arch« erzeugen müssen und die unabhängigen Pakete im
debian/rules-Ziel »binary-indep«.
Um dies zu erleichtern sowie Ihnen mehr Kontrolle darüber zu geben, auf welche Pakete
Debhelper-Programme einwirken, akzeptieren alle Debhelper-Programme die Parameter -a, -i,
-p und -s. Diese Parameter sind kumulativ. Falls keiner angegeben wurde, wirken Debhelper-
Programme standardmäßig auf alle Paketen ein, die in der Datei »control« aufgeführt sind,
mit nachfolgenden Ausnahmen.
Zuerst werden alle Pakete, deren Architecture-Feld in debian/control nicht mit der
DEB_HOST_ARCH-Architektur übereinstimmt, ausgeschlossen ("Debian Policy, Abschnitt
5.6.8").
Außerdem können einige zusätzliche Paket basierend auf dem Inhalt der Umgebungsvariable
DEB_BUILD_PROFILES und den Feldern Build-Profiles in den Absätzen für binäre Pakete in
debian/control ausgeschlossen werden. Dies geschieht gemäß der Entwurfrichtlinie unter
<https://wiki.debian.org/BuildProfileSpec>.
Zusammenspiel zwischen Paketauswahl und Bauprofilen
Bauprofile beeinflussen, welche Pakete im Paketauswahlmechanismus von Debhelper enthalten
sind. Im Allgemeinen wird die Paketauswahl unter der Annahme beschrieben, dass alle Pakete
aktiviert sind. Dieser Abschnitt beschreibt, wie die Auswahl reagiert, wenn ein Paket
aufgrund des aktiven Bauprofils (oder das Fehlen des aktiven Bauprofils) deaktiviert wird.
-a/--arch, -i/--indep ODER keine Auswahloptionen (ein roher »dh_X«-Aufruf)
Das durch Bauprofile deaktivierte Paket wird stillschweigend aus der Auswahl
ausgeschlossen.
Beachten Sie, dass Sie eine Warnung bekommen, falls alle zu dieser Auswahl gehörenden
Pakete deaktiviert werden. In diesem Fall ist der Bau im Allgemeinen überhaupt
sinnlos.
-N Paket / --no-package Paket
Die Option wird akzeptiert und hat keine Wirkung.
-p Paket / --package Paket
Die Option wird akzeptiert, aber Debhelper wird nichts an dem Paket ändern.
Beachten Sie, dass es keine Rolle spielt, ob das Paket standardmäßig aktiviert oder
deaktiviert ist.
Automatisches Erzeugen von Debian-Installationsskripten
Einige Debhelper-Befehle werden automatisch Teile der Debian-Betreuerskripte erzeugen.
Falls Sie diese automatisch erzeugten Dinge in Ihre existierenden Debian-Betreuerskripte
einfügen möchten, dann müssen Sie Ihren Skripten #DEBHELPER# an der Stelle platzieren, an
die der Kode hinzugefügt werden soll. #DEBHELPER# wird bei der Ausführung durch beliebigen
automatisch erzeugten Kode ersetzt, wenn Sie dh_installdeb ausführen.
Falls ein Skript noch gar nicht existiert und Debhelper etwas darin hinzufügen muss, dann
wird Debhelper das komplette Skript erstellen.
Alle Debhelper-Befehle, die auf diese Art automatisch Kode erzeugen, lassen ihn durch den
Parameter -n deaktiviert (siehe oben).
Beachten Sie, dass der eingefügte Kode Shell-Kode sein wird. Sie können ihn daher nicht
direkt in einem Perl-Skript verwenden. Falls Sie ihn in ein Perl-Skript einbetten wollen,
wird hier eine Möglichkeit dafür beschrieben (beachten Sie, dass über den Befehl »set«
sichergestellt wird, dass $1, $2, etc. gesetzt sind):
my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
#DEBHELPER#
EOF
if (system($temp)) {
my $exit_code = ($? >> 8) & 0xff;
my $signal = $? & 0x7f;
if ($exit_code) {
die("Das Debhelper-Skript scheiterte mit folgendem Fehlercode: ${exit_code}");
} else {
die("Das Debhelper-Skript wurde per Signal abgebrochen: ${signal}");
}
}
Automatisches Erzeugen verschiedener Abhängigkeiten
Einige Debhelper-Befehle könnten dazu führen, dass das erzeugte Paket von einigen anderen
Paketen abhängt. Falls Sie beispielsweise dh_installdebconf(1) benutzen, wird Ihr Paket
von Debconf abhängen müssen. Oder, falls Sie dh_installxfonts(1) verwenden, wird ihr Paket
generell von einer bestimmten Version der Xutils abhängen. Den Überblick über diese
verschiedenen Abhängigkeiten zu behalten kann lästig sein, da sie von Debhelpers
Arbeitsweise abhängen, weswegen Debhelper eine Möglichkeit bietet, sie zu automatisieren.
Für jeden Befehl werden die benötigten Abhängigkeiten in den Handbuchseiten dokumentiert.
Daneben wird automatisch eine »substvar« erzeugt, die ${misc:Depends} genannt wird. Falls
Sie eine Markierung in Ihre debian/control-Datei schreiben, wird es sie zu den
Abhängigkeiten expandieren, von denen Debhelper findet, dass Sie sie benötigen.
Dies ist gänzlich unabhängig von dem vorgegebenen ${shlibs:Depends}, das durch
dh_makeshlibs(1) erzeugt wurde, und den durch dh_perl(1) erzeugten ${perl:Depends}. Sie
können sich entscheiden, keines davon benutzen, falls die Einschätzung von Debhelper nicht
der Wirklichkeit entspricht.
Paketbauverzeichnisse
Standardmäßig gehen alle Debhelper-Programme davon aus, dass das temporäre Verzeichnis,
das zum Zusammenbau des Dateibaums in einem Paket benutzt wird, debian/Paket ist.
Manchmal wollen Sie möglicherweise ein anderes temporäres Vezeichnis benutzen. Dies wird
durch den Schalters -P unterstützt. »dh_installdocs -Pdebian/tmp« wird zum Beispiel
debian/tmp als temporäres Verzeichnis nutzen. Beachten Sie, dass die Debhelper-Programme
nur auf ein einzelnes Paket auf einmal einwirken können, wenn Sie -P verwenden. Falls Sie
ein Paket haben, das mehrere Binärpakete baut, müssen Sie zusätzlich den Schalter -p
einsetzen, um anzugeben, auf welches Binärpaket sich das Debhelper-Programm auswirkt.
Udebs
Debhelper beinhaltet Unterstützung für Udebs. Um ein Udeb mit Debhelper zu erstellen,
fügen Sie dem Absatz des Pakets in debian/control »Package-Type: udeb« hinzu. Debhelper
wird versuchen, Udebs zu erstellen, die der Debian-Installer-Richtlinie entsprechen, indem
die erzeugten Paketdateien mit .udeb enden, keine Dokumentation in ein Udeb installiert
wird und preinst-, postrm-, prerm- sowie config-Skripte etc. übersprungen werden.
UMGEBUNGSVARIABLEN
Dieser Abschnitt beschreibt einige der Umgebungsvariablen, die das Verhalten von Debhelper
beeinflussen oder mit denen Debhelper interagiert.
Es ist wichtig, darauf hinzuweisen, dass es echte Umgebungsvariablen (nicht nur einfache
Makefile-Variablen) sein müssen, damit dies korrekt funktioniert. Um sie ordnungsgemäß in
debian/rules anzugeben, müssen Sie sicherstellen, dass sie »export«iert werden, zum
Beispiel »export DH_VERBOSE«.
DH_VERBOSE
auf 1 gesetzt, um den Modus mit detailreicher Ausgabe zu aktivieren. Debhelper wird
jeden von ihm ausgeführten Befehl ausgeben. Außerdem wird die detailreiche Ausgabe von
Bauprotokollen für einige Bausysteme wie Autoconf aktiviert.
DH_QUIET
auf 1 gesetzt, um den detailarmen Modus zu aktivieren. Debhelper wird weder Befehle
ausgeben, die das Bausystem der Ursprungsautoren aufrufen, noch wird Dh ausgeben,
welche Unterbefehle aufgerufen werden. Abhängig vom benutzten Bausystem wird auch
dieses weniger Details ausgeben. Dadurch wird es einfacher, wichtige Nachrichten zu
erkennen, die Ausgabe wird jedoch als Buildd-Protokoll ziemlich nutzlos. Falls
DH_VERBOSE ebenfalls gesetzt ist, wird diese Einstellung ignoriert.
DH_COMPAT
gibt vorübergehend an, auf welcher Kompatibilitätsstufe Debhelper ausgeführt werden
soll und setzt dabei jeden Wert außer Kraft, der über Build-Depends in Debhelper-
compat oder über die Datei debian/compat angegeben wurde.
DH_NO_ACT
auf 1 gesetzt, um Modus ohne Aktion zu aktivieren.
DH_OPTIONS
Alle Debhelper-Werkzeuge werden die in dieser Variable aufgeführten Argumente vor
ihren eigenen Befehlszeilenargumenten auswerten (als ob sie den
Befehlszeilenargumenten vorangestellt worden wären). Leider unterstützen einige von
Dritten bereitgestellte Werkzeuge diese Variable möglicherweise nicht und werden diese
Befehlszeilenargumente ignorieren.
Wenn dh(1) benutzt wird, können ihm Optionen übergeben werden, die es an jeden
Debhelper-Befehl weitergibt, was im Allgemeinen besser ist, als DH_OPTIONS zu
verwenden.
DH_ALWAYS_EXCLUDE
Falls gesetzt, fügt dies den Wert der Variablen den -X-Optionen aller Befehle hinzu,
welche die Option -X unterstützen. Außerdem wird dh_builddeb für alles in Ihrem
Paketbaubaum, das dem Wert entspricht, rm -rf ausführen.
Dies kann nützlich sein, wenn Sie aus einem CVS-Quellverzeichnisbaum bauen. In diesem
Fall verhindert das Setzen von DH_ALWAYS_EXCLUDE=CVS, dass sich irgendwelche CVS-
Verzeichnisse in das Paket einschleichen, das Sie bauen. Oder, falls ein Paket einen
Quell-Tarball hat, der (unklugerweise) CVS-Verzeichnisse enthält, möchten Sie
möglicherweise DH_ALWAYS_EXCLUDE=CVS in debian/rules exportieren, damit es wirksam
ist, wo auch immer Ihr Paket gebaut wird.
Mehrere Dinge, die ausgeschlossen werden sollen, können mit Doppelpunkten getrennt
werden, wie in DH_ALWAYS_EXCLUDE=CVS:.svn.
DH_EXTRA_ADDONS
Falls gesetzt, fügt dies die angegebenen Dh-Erweiterungen hinzu, die an den
entsprechenden Stellen in den Befehlssequenzen ausgeführt werden. Dies entspricht der
Angabe der auszuführenden Erweiterung mit dem Schalter --with in der Datei
»debian/rules«. Alle --without-Aufrufe, die in dieser Umgebungsvariable eine
Erweiterung festlegen, werden nicht ausgeführt.
Dies ist für die Benutzung durch nachgeschaltete Distributionen oder spezielle lokale
Konfigurationen gedacht, die während mehrerer Bauvorgänge eine Debhelper-Erweiterung
ausführen müssen, ohne dass eine große Anzahl von Regeldateien bearbeitet werden muss.
Falls überhaupt möglich, sollte dies zugunsten eines --with-Schalters in der Datei
»rules« vermieden werden.
DH_COLORS, DPKG_COLORS
Diese Variablen können benutzt werden, um zu steuern, ob Debhelper-Befehle in ihrer
Textausgabe Farben benutzen sollen. Sie können auf »always«, »auto« (die
Voreinstellung) oder »never« gesetzt werden.
Beachten Sie, dass DPKG_COLOR auch mehrere mit Dpkg verbunden Werkzeuge beeinflusst
und Debhelper es unter der Annahme benutzt, dass Sie dieselbe Farbeinstellung für Dpkg
und Debhelper benutzen wollen. In dem unwahrscheinlichen Fall, dass Sie für Debhelper
eine andere Farbeinstellung möchten, können Sie DH_COLORS statt oder zusätzlich zu
DPKG_COLORS verwenden.
NO_COLOR
Falls nicht explizit um Farbe gebeten wurde (sowohl DH_COLORS als auch DPKG_COLORS
sind nicht gesetzt), führt die Anwesenheit dieser Umgebungsvariablen dazu, dass die
Standardfarbeinstellung auf »never« gesetzt wird.
Die Variable ist gemäß <https://no-color.org/> definiert. In diesem Projekt werden die
Umgebungsvariablen (wie DH_COLORS) als explizite Farbanfrage betrachtet.
CFLAGS, CPPFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS, FCFLAGS, LDFLAGS
Standardmäßig (in jeder nicht missbilligten Kompatibilitätsstufe) wird Debhelper diese
Schalter automatisch mittels dpkg-buildflags(1) setzen, wenn sie nicht gesetzt sind.
Falls Sie die voreingestellten Schalter ändern wollen, benutzen Sie dazu die
Funktionalität von dpkg-buildflags(1) (z.B. DEB_BUILD_MAINT_OPTIONS=hardening=all oder
DEB_CPPFLAGS_MAINT_APPEND=-DCUSTOM_MACRO=true) statt die konkrete Variable direkt zu
setzen.
HOME, XDG_*
In Kompatibilitätsstufe 13 und später werden diese Umgebungsvariablen zurückgesetzt,
bevor das Originalautoren-Bausystem via dh_auto_* angeworfen wird. Die HOME-
(dh_auto_*-Hilfsprogramme) und die XDG_RUNTIME_DIR-Variable (nur dh_auto_test) werden
auf ein beschreibbares Verzeichnis gesetzt. Alle anderen Variablen und XDG_RUNTIME_DIR
(außer während des dh_auto_test) werden geleert.
Die Verzeichnisse werden leer erzeugt und zwischen den dh_auto_*-Aufrufen
wiederverwendet. Jeglicher Inhalt wird weiter bestehen, bis er explizit gelöscht oder
dh_clean aufgerufen wird.
DEB_BUILD_OPTIONS
Die Beschreibung dieser Umgebungsvariable entnehmen Sie bitte "Unterstützte Optionen
in DEB_BUILD_OPTIONS"
Bitte beachten Sie, dass diese Variable von Paketbetreuern in ihren debian/rules nicht
geändert werden sollte, um das Verhalten von Debhelper zu beeinflussen. Stattdessen
sollen die fraglichen Funktionsmerkmale direkt abgeschaltet werden (etwa durch
Außerkraftsetzen der betreffenden Werkzeuge).
DEB_BUILD_MAINT_OPTIONS
Dies ist eine Dpkg-spezifische Umgebungsvariable (siehe dpkg-buildflags(1)). Die
Debhelper-Suite ignoriert sie kommentarlos.
Sie ist hier dokumentiert, weil ihr Name DEB_BUILD_OPTIONS ähnelt, was zu der falschen
Annahme verleiten kann, dass Debhelper die Variable genauso auf die Variable reagiert.
Unterstützte Optionen in DEB_BUILD_OPTIONS
Die Debhelper-Suite reagiert auf die folgenden Optionen in DEB_BUILD_OPTIONS:
dherroron=obsolete-compat-levels>
Dieser Wert ist Debhelper-spezfisch.
Wenn dherroron vorhanden und auf obsolete-compat-levels gesetzt ist, werden die
Debhelper-Werkzeuge die Missbilligungswarnungen für auf der Abschussliste stehenden
Kompaitiblitätsstufen zu Fehlern erheben.
Dies hilft bei automatischen Überprüfungen, ob Kode auf veralteten
Kompatibilitätsstufen basiert, die bald entfernt werden sollen.
Die Option ist für Testzwecke gedacht, aber nicht für Produktiveinsatz.
nostrip
Dieser Wert ändert den Inhalt der Debs, die gebaut werden. Die .deb-Pakete, die unter
Anwesenheit dieses Werts gebaut werden, werden nicht Bit für Bit reproduzierbar sein,
was bei einem gewöhnlichen Paket der Regelfall ist.
Durch diesen Wert werden die offiziellen Debhelper-Werkzeuge dazu gebracht, Aktionen
und Hilfsprogramme zum Entfernen, Abkoppeln oder Deduplizieren von Fehlersuchsymbolen
in ELF-Binärdateien zu überspringen.
Dieser Wert betrifft dh_dwz(1) und dh_strip(1).
nocheck
Dieser Wert führt dazu, dass die offiziellen Debhelper-Bausysteme die Ausführung von
Test-Suiten der Originalautoren überspringen.
Paketbetreuer, die versuchen, diese Tests zu umgehen, sollten sich hierauf nicht
verlassen. Stattdessen können sie ein leeres Override-Ziel angeben, um dh_auto_test zu
überspringen.
Dieser Wert betrifft dh_auto_test(1).
nodoc
Dieser Wert ändert den Inhalt der Debs, die gebaut werden. Die .deb-Pakete, die unter
Anwesenheit dieses Werts gebaut werden, werden nicht Bit für Bit reproduzierbar sein,
was bei einem gewöhnlichen Paket der Regelfall ist.
Dieser Wert wird mehrere Debhelper-Tools anweisen, die Installation von Dokumentation
wie Handbuchseiten oder von den Originalautoren bereitgestellte Dokumentation
auszulassen. Außerdem werden die Werkzeuge es ignorieren, wenndie deklarierte
Dokumentation fehlt, unter der Annahme, dass sie nicht gebaut wurde.
Dieser Wert betrifft Werkzeuge wie dh_installdocs(1), welches weiß, dass es mit
Dokumentation arbeitet.
noautodbgsym, noddebs
Der offizielle Name ist noautodbgsym. Die noddebs-Variante wird aus historischen
Gründen akzeptiert.
Dieser Wert veranlasst Debhelper, die automatische Erzeugung der Fehlersuchsymbol-
Pakete zu unterlassen.
Dieser Wert beeinflusst dh_strip(1).
parallel=N
Dieser Wert erlaubt es Debhelper, bis zu N Threads oder Prozesse (eingeschränkt durch
Parameter wie --no-parallel und --max-parallel=M) zu verwenden. Nicht alle Debhelper-
Werkzeuge arbeiten parallel und können die Anfrage daher kommentarlos ignorieren.
Dieser Wert betrifft viele Debhelper-Werkzeuge. Vor allem dh_auto_* wird versuchen,
das zugrundeliegende Bausystem der Originalautoren mit dieser Anzahl an Threads
auszuführen.
terse
Dieser Wert wird die offiziellen Debhelper-Bausysteme zu einer knappen, weniger
ausführlichen (daher »terse«) Ausgabe animieren. Seine Wirkung hängt davon ab,
inwieweit das Bausystem der Originalautoren und das von Debhelper solche
Funktionsmerkmale unterstützen.
Dieser Wert betrifft die meisten dh_auto_*-Werkzeuge.
Unbekannte Schalter werden stillschweigend ignoriert.
Beachten Sie, dass Debhelper-ähnliche Werkzeuge oder Bausysteme von Drittherstellern
unterschiedlich auf die oben genannten Schalter reagieren. Das hängt davon ab, wie die
Werkzeuge im Detail implementiert sind.
SIEHE AUCH
debhelper-compat-upgrade-checklist(7)
List of supported compat levels and an upgrade checklist for each of them.
/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>