Provided by: debhelper_13.9.1ubuntu1_all 
NAME
dh - Debhelper-Befehls-Sequenzer
ÜBERSICHT
dh Sequenz [--with Add-on[,Add-on …]] [--list] [Debhelper-Optionen]
BESCHREIBUNG
dh führt eine Sequenz von Debhelper-Befehlen aus. Die unterstützten Sequenzen entsprechen
den Zielen einer debian/rules-Datei: build-arch, build-indep, build, clean, install-indep,
install-arch, install, binary-arch, binary-indep und binary.
OVERRIDE- UND HOOK-ZIELE
Eine debian/rules-Datei, die dh benutzt, kann einen Befehl in jedem Schritt einer Sequenz
außer Kraft setzen, indem sie ein Override-Ziel (Override target) definiert. Es ist auch
möglich, Befehle vor oder nach jedem Schritt einzuspeisen, ohne den Schritt selbst zu
beeinflussen.
Befehle vor oder nach einem Schritt einspeisen
Hinweis: Diese Funktionalität erfordert Debhelper 12.8 oder neuer, zudem muss das Paket
Kompatibilitätsmodus 10 oder neuer nutzen.
Um Befehle vor dh_Befehl einzuspeisen, fügen Sie den Rules-Dateien ein Ziel namens
execute_before_dh_Befehl hinzu. Genauso fügen Sie, wenn Sie nach dh_Befehl Befehle
einspeisen wollen, execute_after_dh_Befehl hinzu. Beide Ziele können für denselben
dh_Befehl benutzt werden und das sogar dann, wenn der Befehl außer Kraft gesetzt wurde
(wie nachfolgend in "Einen Befehl außer Kraft setzen" beschrieben).
Wenn diese Ziele definiert sind, wird dh die Ziele vor beziehungsweise nach dem Aufruf von
dh_Befehl (oder dessen Override-Ziel) aufrufen.
Einen Befehl außer Kraft setzen
Um dh_Befehl außer Kraft zu setzen, fügen Sie der Datei »rules« ein Ziel mit Namen
override_dh_Befehl hinzu. Sobald es normalerweise dh_Befehl ausführen würde, wird dh
stattdessen dieses Ziel aufrufen. Das Override-Ziel kann dann den Befehl mit zusätzlichen
Optionen oder stattdessen ganz andere Befehle ausführen. Siehe die folgenden Beispiele.
Architekturabhängige/-unabhängige Override- und Hook-Ziele
The override and hook targets can also be defined to run only when building architecture
dependent or architecture independent packages. Use targets with names like
override_dh_command-arch and execute_after_dh_command-indep.
Diese Funktionalität ist seit Debhelper 8.9.7 (für Override-Ziele) und 12.8 (für Hook-
Ziele) verfügbar.
Komplett leere Ziele
Als besondere Optimierung wird dh ein Ziel überspringen, falls es komplett leer ist. Dies
eignet sich für Override-Ziele, bei denen der Befehl einfach nur übersprungen und so der
Mehraufwand beim Aufruf eines Scheinziels eingespart wird.
Beachten Sie, das das Ziel komplett leer sein muss, damit dies funktioniert.
# überspringt dh_bar auf die gute und optimierte Art
# hier wird eine Begründung zum Überspringen von dh_bar eingefügt
override_dh_bar:
# überspringt dh_foo auf die langsame Art
override_dh_foo:
# hier wird eine Begründung des Überspringens von dh_foo eingefügt
# (diese Kommentare verursachen die Ausführung eines Scheinziels)
Überprüfung, dass Ziele von dh aufgenommen werden
Um zu bestätigen, dass dh ein Override- oder Hook-Ziel gefunden hat, können Sie
beispielsweise folgenden Befehl verwenden:
$ dh binary --no-act | grep dh_install | head -n5
dh_installdirs
dh_install
debian/rules execute_after_dh_install
dh_installdocs
dh_installchangelogs
Das debian/rules execute_after_dh_install in der Ausgabe zeigt an, dass dh ein
execute_after_dh_install-Ziel registriert hat und es direkt nach dh_install(1) ausführen
würde.
Beachten Sie, dass "Komplett leere Ziele" im oberen Listing weggelassen wurde. Damit wird
es etwas schwieriger zu finden, weil Sie nach der Weglassung eines Befehlsnamens suchen.
Aber andererseits bleibt das Prinzip dasselbe.
Vorbehalte bei Hook-Zielen und Makefile-Bedingungen (conditionals)
Wenn Sie sich entscheiden, ein Hook-Target in Makefile-Bedingungen einzubetten, seien Sie
sich bitte bewusst, dass dh alle Hook-Targets im Voraus berechnet und die Rechenergebnisse
zwischenspeichert. Darüber hinaus werden die Bedingungen später wieder ausgelöst, wenn dh
das Hook-Target aufruft, und es wird dabei davon ausgehen, dass sich die Ergebnisse nicht
geändert haben.
Die Auswertung und das Zwischenspeichern passieren oft schon, bevor dh weiß, ob es Pakete
für arch:any (-a) und/oder arch:all (-i) bauen wird, und kann deswegen verwirrende
Resultate erzielen – vor allem, wenn dh_listpackages(1) Teil der Bedingung ist.
Die meisten Probleme lassen sich vermeiden, indem das Hook-Ziel von Bedingungen befreit
wird und danach der »body«-Teil teilweise oder komplett konditional gemacht wird.
Beispielsweise:
# EINFACH: Es ist durchdefiniert, was passieren wird. Das Hook-Ziel
# wird immer berücksichtigt. Der »vielleicht ausführen«-Teil hat eine
# Bedingung, aber dh_foo wird mit Sicherheit übersprungen.
#
# Hinweis: Der Bedingungsteil wird »zweimal« untersucht, bevor er
# beeinflusst, was passiert. Einmal, wenn dh nachsieht, welche
# Hook-Ziele vorkommen und das zweite Mal, wenn das Hook-Ziel override_dh_foo
# ausgeführt wird. Falls *eines* davon FALSE zurückliefert, wird »vielleicht
# ausführen« übersprungen.
override_dh_foo:
ifneq (...)
vielleicht ausführen
endif
# EINFACH: Dies hier ist genaus durchdefiniert. Das Hook-Ziel wird immer
# ausgeführt und dh_bar wird übersprungen. Der »vielleicht ausführen«-Teil ist
# bedingt, so wie man es erwarten würde.
#
# Hinweis: Die Bedingung wird trotzdem mehrmals überprüft (jedes
# Mal in einem anderen Prozess). Nur die Untersuchung während des
# Laufs des Hook-Ziels beeinflusst, was passiert.
override_dh_bar:
: # Scheinbefehl, der erzwingt, dass das Ziel immer ausgeführt wird
ifneq (...)
vielleicht ausführen
endif
# KOMPLIZIERT: Dieser Fall ist ggf. nicht trivial und hat seine Haken.
# Benutzen Sie es auf eigene Verantwortung, wenn dh_listpackages in der Bedingung steckt.
#
# Hier wird entweder dh_baz normal ODER stattdessen »vielleicht ausführen« ausgeführt.
#
# Es wird noch komplizierter, wenn die Frage aufkommt, ob dh in
# debian/rules rekursiv arbeiten muss, weil Sie ein »explicit« Standardziel
# (z. B. ein »build-arch:«-Ziel, das von »%:« getrennt ist) haben.
ifneq (...)
override_dh_baz:
vielleicht ausführen
endif
Diese Rezepte funktionieren auch bei bedingten Abhängigkeitszielen, die oft in einer
Abwandlung des folgenden Beispiels anzutreffen sind:
COND_TASKS =
ifneq (...)
COND_TASKS += vielleicht-ausführen
endif
...
vielleicht-ausführen:
...
# EINFACH: Es ist durchdefiniert, was passiert. Die
# $(COND_TASKS) werden entweder übersprungen oder nicht.
#
# Hinweis: Die Bedingung wird »zweimal« überprüft und beeinflusst immer,
# was passiert. Einmal, wenn dh nachsieht, welche Hook-Ziele
# vorhanden sind, und einmal, wenn das Hook-Ziel override_dh_foo
# ausgeführt wird. Wenn bei *einem* der beiden Male ein FALSE # zurückgeliefert wird, wird $(COND_TASKS) übersprungen
override_dh_foo: $(COND_TASKS)
# EINFACH: Dieses hier ist genauso durchdefiniert. Das Hook-Ziel
# wird ausgeführt und dh_bar wird übersprungen. Der $(COND_TASKS)-Teil
# ist so bedingt wie man erwarten würde.
#
# Hinweis: Die Bedingung wird trotzdem mehrmals überprüft (jedes # Mal in einem anderen Prozess. Nur die Überprüfung während des Laufs des
# Hook-Ziels beeinflusst, was passiert.
override_dh_bar: $(COND_TASKS)
: # Scheinbefehl, der das Ziel zwingt, immer ausgeführt zu werden
# KOMPLIZIERT: Dieser Fall kann kompliziert sein und seine Haken haben.
# Verwenden Sie es auf Ihre eigene Verantwortung, wenn dh_listpackages in der Bedingung vorkommt.
#
ifneq (...)
override_dh_baz: $(COND_TASKS)
endif
Im Zweifelsfall suchen Sie sich eins der EINFACHEN Fallbeispiele aus, welches zu Ihrem
Bedarf passt.
OPTIONEN
--with Erweiterung[,Add-on …]
fügt die Debhelper-Befehle, die durch die genannte Erweiterung angegeben wurden an
geeigneten Stellen der ausgeführten Befehlssequenz hinzu. Diese Option kann mehr als
einmal wiederholt werden oder es können mehrere Add-ons durch Kommas getrennt
aufgeführt werden. Dies wird benutzt, wenn es ein Fremdpaket gibt, das Debhelper-
Befehle bereitstellt. Dokumentation über die Sequenz-Erweiterungsschnittstelle finden
Sie in der Datei PROGRAMMING.
Eine Build-Depends-Beziehung zum Paket dh-sequence-Erweiterung setzt eine
--with-Erweiterung voraus. Das vermeidet, dass ein explizites --with in debian/rules
benötigt wird, das nur dupliziert, was bereits über die Bauabhängigkeiten in
debian/control erklärt wurde. Die Beziehung kann (seit 12.5) optional gemacht werden,
z. B. über Bauprofile. Dies versetzt Sie in die Lage, einfach eine Erweiterung zu
deaktivieren, die nur zu einem bestimmten Profil passt (z. B. um Bootstrapping zu
erleichtern).
Ab Debhelper 12.5 können Erweiterungen auch im reinen indep-Modus (über Build-Depends-
Indep) oder reinen arch-Modus (über Build-Depends-Arch) aktiviert werden. Derartige
Erweiterungen sind nur in der bestimmten Sequenz aktiv (z. B. binary-indep), die
Abhängigkeitsverwaltung für Cross-Bauen vereinfachen.
Bitte beachten Sie, dass Erweiterungen, die über Build-Depends-Indep oder Build-
Depends-Arch aktiviert wurden, zusätzlichen Beschränkungen unterliegen, die
sicherzustellen, dass das Ergebnis sogar dann deterministisch ist, wenn die
Erweiterung nicht verfügbar ist (z. B. während des Aufräumens). Dies impliziert, dass
einige Erweiterungen mit diesen Beschränkungen inkompatibel sind und nur über Build-
Depends (oder manuell ber debian/rules) benutzt werden können. Derzeit können
derartige Erweiterungen nur Befehle zu Sequenzen hinzufügen.
--without Erweiterung
das Gegenteil von --with, deaktiviert die Benutzung der angegebenen Erweiterung. Diese
Option kann mehrfach wiederholt werden oder es können mehrere Erweiterungen zum
Deaktivieren durch Kommas getrennt aufgelistet werden.
--list, -l
listet alle verfügbaren Erweiterungen auf.
Wenn es nur mit dieser Option aufgerufen wird, kann dh aus jedem Verzeichnis
aufgerufen werden (d.h. es benötigt keinen Zugriff auf Dateien aus einem Quellpaket).
--no-act
gibt Befehle aus, die für eine angegebene Sequenz ausgeführt würden, führt sie aber
nicht aus
Beachten Sie, dass dh normalerweise die Ausführung von Befehlen, von denen es weiß,
dass sie nichts tun, überspringt. Mit »--no-act« wird die vollständige Liste der
Befehle der Reihe nach ausgegeben.
Andere an dh übergebene Optionen werden an jeden Befehl, den es ausführt, weitergereicht.
Damit kann eine Option wie -v, -X oder -N sowie spezialisiertere Optionen gesetzt werden.
BEISPIELE
Um zu sehen, welche Befehle in einer Sequenz enthalten sind, ohne tatsächlich etwas zu
tun, geben Sie Folgendes ein:
dh binary-arch --no-act
Dies ist eine sehr einfache »rules«-Datei für Pakete, bei denen die vorgegebenen
Befehlssequenzen ohne zusätzliche Optionen arbeiten.
#!/usr/bin/make -f
%:
dh $@
Oft möchten Sie eine Option an einen speziellen Debhelper-Befehl übergeben. Der einfachste
Weg, dies zu tun, besteht darin, ein Override-Ziel für diesen Befehl hinzuzufügen.
#!/usr/bin/make -f
%:
dh $@
override_dh_strip:
dh_strip -Xfoo
override_dh_auto_configure:
dh_auto_configure -- --with-foo --disable-bar
Manchmal ist ein Paket den dh_auto_configure(1) und dh_auto_build(1) so fremd, dass sie
nicht automaitsch einschätzen können, was daran zu machen ist. Um ihre Ausführung zu
verhindern und stattdessen Ihre eigenen Befehle einzusetzen, schreiben Sie Folgendes:
#!/usr/bin/make -f
%:
dh $@
override_dh_auto_configure:
./mondoconfig
override_dh_auto_build:
mach-dass-sich-das-Universum-in-Wohlgefallen-auflöst
Ein weiterer häufiger Fall ist, dass Sie vor oder nach der Ausführung eines besonderen
Debhelper-Befehls manuell etwas tun möchten.
#!/usr/bin/make -f
%:
dh $@
# Beispiel geht von Debhelper/12.8 und Kompatibilitätsstufe 10+ aus
execute_after_dh_fixperms:
chmod 4755 debian/foo/usr/bin/foo
Falls Sie auf einer älteren Debhelper-Kompatibilitätsstufe sind, würde das Beispiel wie
folgt aussehen:
#!/usr/bin/make -f
%:
dh $@
# ältere Debhelper-Versionen oder Verwendung von Kompatibilitätsstufe 9
#und niedriger
override_dh_fixperms:
dh_fixperms
chmod 4755 debian/foo/usr/bin/foo
Python-Werkzeuge werden aufgrund ständiger Änderungen in diesem Bereich nicht
standardmäßig von dh ausgeführt. Sie können dh_python2 folgendermaßen benutzen.
#!/usr/bin/make -f
%:
dh $@ --with python2
So wird die Benutzung von Perls Bausystem Module::Build erzwungen wird, was nötig sein
kann, falls Debhelper fälschlicherweise feststellt, dass das Programm MakeMaker verwendet.
#!/usr/bin/make -f
%:
dh $@ --buildsystem=perl_build
Hier ein Beispiel für das außer Kraft setzen, wobei die dh_auto_*-Befehle den
Paketquelltext für ein Paket finden, bei dem der Quelltext in einem Unterverzeichnis
liegt.
#!/usr/bin/make -f
%:
dh $@ --sourcedirectory=src
Und hier ist ein Beispiel, wie dh_auto_*-Befehlen mitgeteilt wird, dass in einem
Unterverzeichnis gebaut wird, das beim Aufräumen entfernt wird.
#!/usr/bin/make -f
%:
dh $@ --builddirectory=build
Falls Ihr Paket parallel gebaut werden kann, benutzen Sie bitte entweder
Kompatibilitätsmodus 10 oder übergeben Sie --parallel an Dh. Dann wird dpkg-buildpackage
-j funktionieren.
#!/usr/bin/make -f
%:
dh $@ --parallel
Falls Ihr Paket nicht verlässlich unter Verwendung mehrerer Threads gebaut werden kann,
übergeben Sie bitte --no-parallel an Dh (oder den zuständigen dh_auto_*-Befehl):
#!/usr/bin/make -f
%:
dh $@ --no-parallel
Es folgt eine Möglichkeit, die Ausführung mehrerer Befehle, die Sie nicht ausführen
möchten, durch dh zu verhindern, indem Sie leere Override-Ziele für jeden Befehl
definieren.
#!/usr/bin/make -f
%:
dh $@
# nicht auszuführende Befehle:
override_dh_auto_test override_dh_compress override_dh_fixperms:
Ein langer Bauprozess für ein separates Dokumentationspaket kann durch Benutzung von
architekturabhängigen Außerkraftsetzungen (Overrides) abgetrennt werden. Diese Ziele
werden übersprungen, wenn »build-arch«- und »binary-arch«-Sequenzen ausgeführt werden.
#!/usr/bin/make -f
%:
dh $@
override_dh_auto_build-indep:
$(MAKE) -C docs
# Keine Tests für Dokumente nötig
override_dh_auto_test-indep:
override_dh_auto_install-indep:
$(MAKE) -C docs install
Angenommen, Sie möchten zusätzlich zum vorhergehenden Beispiel die Dateimodusbits einer
Datei ändern, aber nur, wenn Sie ein architekturabhängiges Paket bauen, da sie beim Bauen
der Dokumentation nicht vorhanden ist.
# Beispiel geht von Debhelper/12.8 und Kompatibilitätsstufe 10+ aus
execute_after_dh_fixperms-arch:
chmod 4755 debian/foo/usr/bin/foo
DEBHELPER PROVIDED DH ADDONS
The primary purpose of dh addons is to provide easy integration with third-party provided
features for debhelper. However, debhelper itself also provide a few sequences that can be
useful in some cases. These are documented in this list:
build-stamp
A special addon for controlling whether dh (in compat 10 or later) will create stamp
files to tell whether the build target has been run successfully. See "INTERNALS" for
more details.
This addon is active by default but can disabled by using dh $@ --without build-stamp
dwz (obsolete)
Adds dh_dwz(1) to the sequence in compat level 11 or below. Obsolete in compat 12 or
later.
elf-tools
This addon adds tools related to ELF files to the sequence such as dh_strip(1) and
dh_shlibdeps(1)
This addon is conditionally active by default for architecture specific packages -
that is, it is skipped for arch:all packages. In the special case where you need these
tools to work on arch:all packages, you can use --with elf-tools to activate it
unconditionally.
installinitramfs (obsolete)
Adds dh_installinitramfs(1) to the sequence in compat level 11 or below. Obsolete in
compat 12 or later.
root-sequence (internal)
This is reserved for internal usage.
single-binary
A special-purpose addon that makes debhelper run in "single binary" mode.
When active, it will pass --destdir=debian/package/ to dh_auto_install(1). This makes
every file "installed" by the upstream build system part of the (only) binary package
by default without having to use other helpers such as dh_install(1).
The addon will refuse to activate when the source package lists 2 or more binary
packages in debian/control as a precaution.
Before compat 15. this behaviour was the default when there was only a single binary
package listed in debian/control. In compat 15 and later, this addon must explicitly
be activated for this feature to work.
The rationale for requiring this as an explicit choice is that if it is implicit then
debhelper will silently change behaviour on adding a new binary package. This has
caused many RC bugs when maintainers renamed a binary and added transitional packages
with the intention of supporting seamless upgrades. The result would often be two
empty binary packages that were uploaded to archive with users frustrated as their
"upgrade" removed their programs.
systemd (obsolete)
Adds dh_systemd_enable(1) and dh_systemd_start(1) to the sequence in compat level 10
or below. Obsolete in compat 11 or later.
INTERNA
Falls Sie neugierig auf die Interna von dh sind, ist hier beschrieben, wie es unter der
Haube arbeitet.
Im Kompatibilitätsmodus 10 (oder höher) erzeugt dh eine Stempeldatei
debian/debhelper-build-stamp, nachdem die Bauschritte abgeschlossen sind, um ein erneutes
Ausführen zu vermeiden. Es ist möglich, die Stempeldatei zu verhindern, indem
--without=build-stamp an dh übergeben wird. Dies sorgt dafür, dass »unsauber« gebaute
Pakete sich eher so verhalten, wie es manche Leute erwarten. Allerdings wird der Bau und
das Testen möglicherweise zweimal ausgeführt (das zweite Mal als root oder unter
fakeroot(1)).
Innerhalb eines Override-Ziels werden dh_*-Befehle eine
debian/package.debhelper.log-Protokolldatei erzeugen, um den Überblick zu behalten, für
welche Pakete die Befehle ausgeführt wurden. Diese Protokolldateien werden entfernt,
sobald die Override-Ziele erledigt sind.
Im Kompatibilitätsmodus 9 oder älter wird jeder Debhelper-Befehl in
debian/package.debhelper.log aufgezeichnet, wenn er erfolgreich ausgeführt wurde. (Was
durch dh_clean gelöscht wird.) Daher kann dh sagen, welche Befehle bereits für welche
Pakete ausgeführt wurden und die erneute Ausführung dieser Befehle überspringen.
Jedes Mal, wenn dh (im Kompatibilitätsmodus 9 oder älter) ausgeführt wird, geht es das
Protokoll durch, um festzustellen, welcher Befehl in der angegebenen Sequenz zuletzt
ausgeführt wurde. Es fährt dann mit dem nächsten Befehl fort.
Eine Sequenz kann außerdem abhänge Ziele in debian/rules ausführen. Die Sequenz »binary«
führt zum Beispiel das Ziel »install« aus.
dh benutzt die Umgebungsvariable DH_INTERNAL_OPTIONS, um Informationen an die Debhelper-
Befehle durchzureichen, die innerhalb der Ziele ausgeführt werden. Der Inhalt (und die
tatsächliche Existenz) dieser Umgebungsvariable ist, wie der Name schon andeutet,
Gegenstand dauernder Änderungen.
Befehle in den Sequenzen build-indep, install-indep und binary-indep werden an die Option
-i übergeben, um sicherzustellen, dass sie nur auf architekturunabhängigen Paketen
funktionieren. Befehle in den Sequenzen build-arch, install-arch und binary-arch werden an
die Option -a übergeben, um sicherzustellen, dass sie nur auf architekturabhängigen
Paketen funktionieren.
SIEHE AUCH
debhelper(7)
Dieses Programm ist Teil von Debhelper.
Ü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>