Provided by: debhelper_9.20160115ubuntu3_all 
NAME
debhelper - die Debhelper-Werkzeugsammlung
ÜBERSICHT
dh_* [-v] [-a] [-i] [-s] [--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.
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 Verweise 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 Fenster-Manager
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_testdir(1)
Verzeichnis vor dem Bauen des Debian-Pakets testen
dh_testroot(1)
stellt sicher, dass ein Paket als Root gebaut wird.
dh_usrlocal(1)
migriert usr/local-Verzeichnisse zu Betreuerskripten
Missbilligte Befehle
Ein paar Debhelper-Befehle sind missbilligt und sollten nicht benutzt werden.
dh_desktop(1)
missbilligt, Leerbefehl
dh_installmanpages(1)
Handbuchseiteninstallationsprogramm im alten Stil (missbilligt)
dh_scrollkeeper(1)
missbilligter Leerbefehl
dh_suidregister(1)
SUID-Registrierungsprogramm (missbilligt)
dh_undocumented(1)
Programm für symbolische Links zu undocumented.7 (missbilligt, Leerbefehl)
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 gegeignet 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 Bauarchitektur 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
Dies wurde als intelligentere Version des Schalters -a benutzt, aber -a ist nun
genauso intelligent.
-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 Pakete
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 neuer) 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 kaputt machen, wurde das Konzept der Debhelper-Kompatibilitätsstufen
eingeführt. Sie teilen Debhelper mit, welche Kompatibilitätsstufe es nutzen sollte und sie
ändern sein Verhalten auf verschiedene Arten.
Schreiben Sie eine Zahl nach debian/compat, um Debhelper mitzuteilen, welche
Kompatibilitätsstufe es nutzen soll. Um beispielsweise in den Modus V9 zu schalten geben
Sie Folgendes ein:
% echo 9 > 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 9 sicherstellen, dass
debian/control Folgendes hat:
Build-Depends: debhelper (>= 9)
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 früheren Kompatibilitätsstufe unterscheidet. Wenn Sie
also nicht die aktuellste Kompatibilitätsstufe benutzen, sind Sie gut beraten, das
Folgende zu lesen, um Hinweise zu erhalten, was sich gegenüber früheren
Kompatibilitätsstufen unterscheidet.
Diese Kompatibilitätsstufen sind verfügbar:
v3 Dies ist die unterste unterstützte Kompatibilitätsstufe.
Dieser Modus ist missbilligt.
v4 Änderungen gegenüber v3 sind:
- dh_makeshlibs -V wird nicht den Debian-Teil der Versionsnummer in der
erzeugten Abhängigkeitslinie in der Shlibs-Datei enthalten.
- Sie werden aufgefordert, das neue ${misc:Depends} in debian/control abzulegen,
um das Feld ${shlibs:Depends} zu ergänzen.
- dh_fixperms wird alle Dateien in bin/-Verzeichnissen und in etc/init.d
ausführbar machen.
- dh_link wird bestehende Verweise korrigieren, damit sie konform mit der
Richtlinie sind.
Dieser Modus ist missbilligt.
v5 Änderungen gegenüber v4 sind:
- Kommentare in Debhelper-Konfigurationsdateien werden ignoriert.
- dh_strip --dbg-package gibt nun den Name des Pakets an, in das Debug-Symbole
getan werden, nicht die Pakete, aus denen die Symbole genommen werden.
- dh_installdocs überspringt die Installation leerer Dateien.
- dh_install gibt Fehlermeldungen aus, wenn Platzhalter zu nichts expandieren.
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 Handbuchseitenverweis 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.
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.
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 Bibliotheken an unüblichen
Speicherplätzen, die dpkg-gensymbols nicht verarbeiten würde, bevor es sie
übergeben bekäme, eine Verhaltenweise ändern, was dazu führen könnte, dass der
Bau einiger Pakete fehlschlagen würde.
- 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.
v9 Dies ist der empfohlene Betriebsmodus.
Ä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.
- Alle dh_auto_*-Debhelper-Programme und dh setzen Umgebungsvariablen, die durch
dpkg-buildflags aufgelistet werden, wenn 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 Debug-Symbole an einer Stelle ab, die auf ihrer
Baukennzahl basiert.
- Ausführbare Debhelper-Konfigurationsdateien werden ausgeführt und ihre Ausgabe
wird als Konfiguration benutzt.
v10 Diese Kompatibilitätsstufe ist immer noch in Entwicklung; benutzen Sie sie mit
Vorsicht.
Ä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 wird auf Pakete, die nur mit
Debhelper-Befehlen bauen, keine Auswirkungen haben, 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 kaputtes 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.
- The dh command will not accept any of the deprecated "manual sequence control"
parameters (--before, --after, etc.). Please migrate to use override targets
instead.
- The dh command will no longer use log files to track which commands have been
run. The dh command still keeps track of whether it already ran the "build"
sequence and skip it if it did.
The main affects of this are:
- With this, it is now easier to debug the install or/and binary sequences
because they can now trivially be re-run (without having to do a full
"clean and rebuild" cycle)
- The main caveat is that dh_* now only keeps track of what happened in a
single override target. When all the calls to a given dh_cmd command
happens in the same override target every thing will work as before.
Example of where it can go wrong:
override_dh_foo:
dh_foo -pmy-pkg
override_dh_bar:
dh_bar
dh_foo --remaining
In this case, the call to dh_foo --remaining will also include my-pkg,
since dh_foo -pmy-pkg was run in a separate override target. This issue is
not limited to --remaining, but also includes -a, -i, etc.
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
Bauarchitektur ü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>.
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.
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>