debhelper(7) | Debhelper | debhelper(7) |
debhelper - die Debhelper-Werkzeugsammlung
dh_* [-v] [-a] [-i] [--no-act] [-pPaket] [-NPaket] [-Ptemporäres_Verzeichnis]
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.
Hier ist die Liste der Debhelper-Befehle, die Sie benutzen können. Zusätzliche Dokumentation finden Sie in deren Handbuchseiten.
Ein paar Debhelper-Befehle sind veraltet und sollten nicht benutzt werden.
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.
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.
In Kompatibilitätsstufe 13 und neuer ist es möglich, in den debhelper-Konfigurationsdateien einfache Ersetzungen für die folgenden Werkzeuge zu verwenden:
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:
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.
# 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.
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.
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).
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:
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.
Die folgenden Befehlszeilenoptionen werden von allen Debhelper-Programmen unterstützt.
Die Option wurde in Kompatibilitätsstufe 12 entfernt.
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.
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.
übergibt none als Bausystem, um automatisches Auswählen zu deaktivieren.
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).
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.
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).
Übrigens bewirkt das Setzen des Maximums auf 1 dasselbe wie die Verwendung von --no-parallel.
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.
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).
Beachten Sie, dass Debhelper Debhelper-Compat nicht für experimentelle oder Beta-Kompatibilitätsstufen bereitstellt. Pakete, die mit diesen Kompatibilitätsstufen experimentieren, sollten debian/compat oder DH_COMPAT verwenden.
Frühere Versionen von Debhelper benötigten die Angabe der Kompatibilitätsstufe in der Datei debian/compat. Das aktuelle Debhelper unterstützt dies zum Zweck der Rückwärtskompatibilität weiterhin, allerdings darf ein Paket eine Kompatibilitätsstufe nicht über mehrere Methoden gleichzeitig angeben. Um diese Methode zu verwenden, sollte debian/compat die Kompatibilitätsstufe als einzelne Zahl enthalten und keinen weiteren Inhalt. Falls Sie die Kompatibilitätsstufe mit dieser Methode angeben, wird Ihr Paket auch eine passende versionierte Bauabhängigkeit mit der gleichen (oder einer höheren) Kompatibiltätsstufe benötigen. Daher sollten Sie, falls Sie die Kompatibilitätsstufe 13 in debian/compat angeben, sicherstellen, dass debian/control Folgendes enthält:
Build-Depends: debhelper (>= 13~)
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.
Folgende Kompatibilitätsstufen sind verfügbar:
Falls Sie ein Upgrade von einer vorhergehenden Kompatibilitätsstufe durchführen, überprüfen Sie bitte debhelper-obsolete-compat(7).
Dieser Modus ist missbilligt.
Dieser Modus ist missbilligt.
Dieser Modus ist missbilligt.
Dieser Modus ist missbilligt.
(Hinfällig, da das Werkzeug dh_pysupport aus Debian Stretch entfernt wurde. Seit Debhelper/10.3 aktiviert dh diese Sequenzerweiterung unabhängig von der Kompatibilitätsstufe nicht mehr.)
Dieser Modus ist missbilligt.
Nachträglich auf frühere Kompatibilitätsstufen angewandt: dh akzeptiert seit Debhelper/12.4 nichts davon mehr.
Die wichtigsten Auswirkungen davon sind:
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 Override-Ziel ausgeführt wird. Dieses Problem ist nicht auf --remaining begrenzt, es umfasst außerdem -a, -i, etc.
Diese Kompatibilitätsfunktionalität hatte einen Fehler seit ihrer Aufnahme in Debhelper/9.20130516, der sie im Kompatibilitätsmodus 9 und älter zum Scheitern brachte. Da es in den fünf Jahren ihres Bestehens keine Berichte zu Problemen gab, die von diesem Fehler verursacht wurden, wurde sie nicht überarbeitet, sondern entfernt.
Von der Kompatibilitätsstufe 11 wird für neue Pakete abgeraten, da sie vvon Funktionalitätswechselwirkungen zwischen dh_installinit und dh_installsystemd betroffen ist, die dazu führen, dass in manchen Fällen Dienste nicht korrekt laufen. Bitte erwägen Sie, stattdessen die Kompatibilitätsstufen 10 oder 12 zu benutzen. Weitere Einzelheiten über das Thema sind in Debian#887904 und <https://lists.debian.org/debian-release/2019/04/msg01442.html> verfügbar.
Änderungen gegenüber v10 sind:
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.
Die große Mehrheit aller Pakete wird von dieser Änderung nicht betroffen sein.
Bekannte Ausnahmen umfassen das Bauen mit dem Profil nodoc, bei dem die obigen Werkzeuge stillschweigend fehlschlagende Suchen mit Mustern erlauben,welche zur Angabe von Dokumentation verwendet werden.
Migrationshinweis: Ein Fehler in Debhelper 11 bis 11.1.5 führte fälschlicherweise dazu, dass dh_installinfo --sourcedir ignoriert hat.
Beachten Sie, dass sie irgendwann komplett hinfällig wird, da die Ursprungsautoren beabsichtigen, die Unterstützung für die Umgebungsvariable PERL_USE_UNSAFE_INC einzustellen. Wenn es so weit ist, wird diese Variable nachträglich auch aus bestehenden Kompatibilitätsstufen entfernt.
Beachten Sie, dass diese Änderung nicht für dieses Quellpaket relevant ist und Sie zur nächsten Änderung springen können, falls ein angegebenes Quellpaket nur ein einziges Binärpaket in debian/control enthält oder keine -doc-Pakete dabei sind.
Standardmäßig werden diese Werkzeuge nun versuchen, ein »Hauptpaket für die Dokumentation« (ab hier Hauptdokumentationspaket genannt) für jedes -doc-Paket zu bestimmen. Falls sie ein derartiges Hauptdokumentationspaket finden, werden sie nun die Dokumentation in den Pfad /usr/share/doc/Hauptdokumentationspaket im angegebenen Dokumentationspaket installieren. Das heißt, der Pfad kann sich ändern, aber die Dokumentation wird immer noch im -doc-Paket mitgeliefert.
Die Option --doc-main-package kann benutzt werden, wenn die automatische Erkennung unzureichend ist oder um den Pfad auf seinen vorherigen Wert zurückzusetzen, falls es einen Grund gibt, von der Empfehlung der Debian-Richlinien abzuweichen.
Manche Dokumentation wird von dieser Änderung nicht beeinflusst. Diese Ausnahmen umfassen die Copyright-Dateien, README.Debian usw. Diese Dateien werden weiterhin im Pfad /usr/share/doc/Paket installiert.
Diese Änderung kann dazu führen, dass mehr Dateien als vorher verarbeitet werden.
Falls eine nicht versionierte Abhängigkeit in der Shlibs-Datei gewünscht wird, kann dies stattdessen durch Übergabe von -VNone erreicht werden. Siehe aber auch dh_makeshlibs(1) für die Vorbehalte gegen nicht versionierte Abhängigkeiten.
Falls ein spezielles Paket der Ursprungsautoren nicht die korrekte Voreinstellung benutzt, kann der Parameter oft manuell per dh_auto_configure(1) übergeben werden, etwa wie im folgenden Beispiel:
override_dh_auto_configure: dh_auto_configure -- --libexecdir=/usr/libexec
Beachten Sie das -- vor dem Parameter --libexecdir.
Falls Sie eine Methode haben, dh_installinit außer Kraft zu setzen (z. B. indem Sie es mit --no-start aufrufen), dann werden Sie jetzt wahrscheinlich auch eine für dh_installsystemd benötigen.
Diese Änderung lässt dh_installinit ein misc:Pre-Depends für init-system-helpers (>= 1.54~) einspeisen. Bitte stellen Sie sicher, dass das Paket ${misc:Pre-Depends} in seinem Feld Pre-Depends aufführt, bevor Sie ein Upgrade auf Kompatibilitätsstufe 12 durchführen.
Die Änderungen gegenüber v12 sind:
Dieses Funktionsmerkmal hat sich zwischen Debhelper 13 und Debhelper 13.2 geändert.
Falls Sie die Warnung gar nicht wollen, lassen Sie bitte den Aufruf von dh_missing weg. Falls Sie den Befehlssequenzer dh benutzen, dann können Sie dies mit einem leeren Override-Ziel in der Datei debian/rules oder dem passenden Paket erledigen. Zum Beispiel:
# Disable dh_missing override_dh_missing:
Beachten Sie, dass dh_installtmpfiles auf debian/Paket.tmpfiles reagiert, wo dh_installsystemd einen Nahmen ohne das nachfolgende »s« benutzt hat.
Bitte lesen Sie "Ersetzungen in Debhelper-Konfigurationsdateien", um mehr über die Syntax und verfügbare Ersetzungsvariablen zu erfahren. An Verfasser von dh_*-Werkzeugen: Die Ersetzung und Expandierung ist Teil der Funktionen filearray und filedoublearray.
Alle Pakete, die sich darauf verlassen, dass diese Ziele immer ausgeführt werden, sollten die betroffene Logik aus diesen Zielen heraus verschieben. Z. B. müsste nicht-testbezogener Paketierungscode von override_dh_auto_test nach execute_after_dh_auto_build oder execute_before_dh_auto_install verschoben werden.
dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...
Änderungen gegenüber v13 sind:
This can cause issues with running binaries directly from the build directories as they might now require a manually set LD_LIBRARY_PATH. If you need to override this change, we recommend that you try to pass the -DCMAKE_SKIP_RPATH=OFF option first to see if that fixes the problem (leaving CMAKE_BUILD_RPATH_USE_ORIGIN at its new default). This should undo the need for LD_LIBRARY_PATH and avoid the reproducibility issues on Linux, where $ORIGIN is supported by the runtime linkers.
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.
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.
Beachten Sie, dass es keine Rolle spielt, ob das Paket standardmäßig aktiviert oder deaktiviert ist.
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}"); } }
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.
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.
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.
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«.
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.
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.
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.
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.
Die Variable ist gemäß <https://no-color.org/> definiert. In diesem Projekt werden die Umgebungsvariablen (wie DH_COLORS) als explizite Farbanfrage betrachtet.
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.
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).
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.
Die Debhelper-Suite reagiert auf die folgenden Optionen in DEB_BUILD_OPTIONS:
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.
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).
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).
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.
Dieser Wert veranlasst Debhelper, die automatische Erzeugung der Fehlersuchsymbol-Pakete zu unterlassen.
Dieser Wert beeinflusst dh_strip(1).
Dieser Wert betrifft viele Debhelper-Werkzeuge. Vor allem dh_auto_* wird versuchen, das zugrundeliegende Bausystem der Originalautoren mit dieser Anzahl an Threads auszuführen.
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.
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
Joey Hess <joeyh@debian.org>
2021-03-06 | 13.3.4 |