Manpages

dh_installmanpages(1)

Handbuchseiteninstallationsprogramm im alten Stil (veraltet)

Weitere Befehle
Falls ein Programmname mit dh_ beginnt und das Programm nicht auf obiger Liste steht, dann ist es nicht Teil des Debhelper-Pakets, sollte aber trotzdem wie die anderen auf dieser Seite beschriebenen Programme funktionieren.

DEBHELPER-KONFIGURATIONSDATEIEN

Viele Debhelper-Befehle machen von den Dateien in debian/ Gebrauch, um zu steuern, was sie tun. Neben den üblichen debian/changelog und debian/control, die in allen Paketen enthalten sind, nicht nur in denen, die Debhelper benutzen, können einige zusätzliche Dateien verwandt werden, um das Verhalten bestimmter Debhelper-Befehle zu konfigurieren. Diese Dateien heißen üblicherweise debian/Paket.foo (wobei Paket natürlich durch das Paket ersetzt wird, auf das es sich auswirkt).

dh_installdocs benutzt beispielsweise Dateien mit dem Namen debian/package.docs, um die Dokumentationsdateien aufzulisten, die es installieren wird. Lesen Sie die Handbuchseiten der einzelnen Befehle, um Einzelheiten über die Namen und Formate der Dateien zu erhalten, die sie verwenden. Im Allgemeinen werden diese Dateien Dateien auflisten, auf die sie einwirken, eine Datei pro Zeile. Einige Programme in Debhelper bedienen sich Paaren von Dateien und Zielen oder etwas kompiziertere Formate.

Beachten Sie, dass Debhelper für das erste (oder einzige) in debian/control 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 compatibility level 13 and later, it is possible to use simple substitutions in debhelper config files for the following tools:

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 Zweifel ist die Variante DEB_HOST_* diejenige, die sowohl für natives als auch für Bauen für andere Architekturen funktioniert.

Aus Leistungsgründen wird Debhelper versuchen, diese Namen aus der Umgebung aufzulösen, bevor es Rat bei dpkg-architecture(1) sucht. Dies ist 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 die Umgebungsvariable NAME . Die Umgebungsvariable muss gesetzt sein (kann aber auf eine leere Zeichenkette gesetzt sein).

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 (sie kann auf eine leere Zeichenkette gesetzt werden).

Ersetzungsbeschränkungen

Um Endlosschleifen und Ressourcenverschwendung zu vermeiden, wird Debhelper mit einer Fehlermeldung stoppen, 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 benutzen, 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 bitte 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.

GEMEINSAM BENUTZTE DEBHELPER-OPTIONEN

Die folgenden Befehlszeilenoptionen werden von allen Debhelper-Programmen unterstützt.
-v, --verbose

Detailreicher Modus: zeigt alle Befehle, die das Paketbauverzeichnis ändern

--no-act

tut nicht wirklich etwas. Falls es mit -v benutzt wird, wird als Ergebnis ausgegeben, was der Befehl getan hätte.

-a, --arch

wirkt sich auf architekturabhängige Pakete aus, die für die Architektur DEB_HOST_ARCH gebaut werden sollen.

-i, --indep

wirkt sich auf alle architekturunabhängigen Pakete aus.

-pPaket, --package=Paket

wirkt sich auf das Paket mit Namen Paket aus. Diese Option kann mehrfach angegeben werden, damit Debhelper mit einer Zusammenstellung von Paketen arbeitet.

-s, --same-arch

missbilligter Alias von -a.

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 zu verarbeiten auflisten.

--remaining-packages

wirkt sich nicht auf die Pakete aus, auf die sich dieser Debhelper-Befehl bereits ausgewirkt hat (d.h. falls der Befehl im Debhelper-Protokoll des Pakets auftaucht). Falls Sie zum Beispiel den Befehl mit speziellen Optionen für nur ein paar Binärakete aufrufen müssen, geben Sie diese Option beim letzten Aufruf des Befehls an, um die restlichen Pakete mit Standardeinstellungen zu verarbeiten.

-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.

-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-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.

ü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, anstatt auf der obersten Verzeichnisebene des Debian-Quellpaketverzeichnisbaums, liegt.

Warning: The --sourcedir variant matches a similar named option in dh_install and dh_missing (etc.) for historical reasons. While they have a similar name, they have very distinct purposes and in some cases it can cause errors when this variant is passed to dh (when then passes it on to all tools).

-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 ein Standardbauverzeichnis benutzt, selbst wenn --builddirectory angegeben wurde.

Falls das Bausystem das Bauen außerhalb des Quellverzeichnisbaums bevorzugt, aber das Bauen innerhalb der Quelle immer noch erlaubt, kann Letzteres wieder aktiviert werden, indem ein Bauverzeichnispfad übergeben wird, der dem Quellverzeichnispfad entspricht.

--parallel, --no-parallel

prüft, ob parallel gebaut werden soll, falls das zugrundeliegende Bausystem dies unterstützt. Die Anzahl paralleler Aufgaben wird zur Bauzeit durch die Umgebungsvariable DEB_BUILD_OPTIONS ("Debian-Richtlinie, Abschnitt 4.9.1") gesteuert, Sie könnte außerdem Gegenstand einer bausystemspezifischen Begrenzung sein.

Falls keine der Optionen angegeben wurde, ist die Voreinstellung von Debhelper derzeit --parallel in Kompatibilitätsversion 10 (oder höher) und andernfalls --no-parallel.

Als Optimierung wird Dh versuchen, die Übergabe dieser Optionen an Unterprozesse zu vermeiden, falls sie unnötig sind und als einzige Optionen übergeben werden. Dies geschieht insbesondere dann, wenn DEB_BUILD_OPTIONS keinen parallel-Parameter hat (oder dessen Wert 1 ist).

--max-parallel=Maximum

Diese Option impliziert --parallel und erlaubt die weitere Begrenzung der Anzahl von Aufgaben, die bei einem parallelen Bauen benutzt werden können. Falls bekannt ist, dass das Bauen des Pakets nur mit einer bestimmten Stufe der Gleichzeitigkeit funktioniert, können Sie diese auf die maximale Stufe setzen, von der bekannt ist, dass sie funktioniert oder auf die, von der Sie wünschen, dass sie unterstützt wird.

Bemerkenswerterweise ist das Setzen des Maximums auf 1 tatsächlich dasselbe wie die Verwendung von --no-parallel.

--reload-all-buildenv-variables

Standardmäßig wird dh(1) mehrere Umgebungen berechnen (z.B. mittels dpkg-buildflags(1)) und sie zwischenspeichern, um zu verhindern, dass alle dh_auto_*-Werkzeuge sie erneut berechnen.

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 ist in sehr seltenen Fällen nützlich, wenn das Paket mehrere Bauvorgänge mit unterschiedlichen …FLAGS-Optionen benötigt. Ein konkretes Beispiel wäre die Notwendigkeit der Änderung des Parameters -O in CFLAGS beim zweiten Bauen:

    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, da dh_auto_configure(1) den zwischengespeicherten Wert von CFLAGS , der durch dh(1) gesetzt wurde, benutzen.

Diese Option ist nur mit debhelper (>= 12.7~) 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 würde oder welches durch die Option --buildsystem manuell angegeben wird.

KOMPATIBILITÄTSSTUFEN

Von Zeit zu Zeit müssen wesentliche, nicht rückwärtskompatible Änderungen an Debhelper vorgenommen werden, um es so ordentlich und gut entworfen wie nötig zu halten und weil sein Autor mehr Erfahrung gewinnt. Um zu verhindern, dass solche wesentlichen Änderungen existierende Pakete beschädigen, wurde das Konzept der Debhelper-Kompatibilitätsstufen eingeführt. Sie müssen Debhelper mitteilen, welche Kompatibilitätsstufe es nutzen soll und es ändert sein Verhalten auf verschiedene Arten.

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 Punktverö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 und das aktuelle Debhelper unterstützt dies immer noch aufgrund der Rückwärtskompatibilität, 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 versionierte Bauabhängigkeit zum Debhelper-Paket benötigen, die gleich der (oder größer als die) Kompatibilitätsstufe ist, die Ihr Paket verwendet. 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 in den meisten Fällen wird nicht angezeigt, wenn sich dieses Verhalten von einer älteren Kompatibilitätsstufe unterscheidet. Wenn Sie also nicht die aktuellste Kompatibilitätsstufe benutzen, ist es eine gute Idee, folgende Hinweise zu den Unterschieden gegenüber älteren Kompatibilitätsstufen zu lesen.

Unterstützte Kompatibilitätsstufen
Folgende Kompatibilitätsstufen sind verfügbar:

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 außer Kraft setzenden 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 keine Berichte zu Problemen gab, die dieser Fehler in circa fünf Jahren verursachte, wurde er entfernt anstatt behoben.

Von der Kompatibilitätsstufe 11 wird für neue Pakete abgeraten, da sie unter Funktionalitätswechselwirkungen zwischen dh_installinit unddh_installsystemd leidet, 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, wobei obige Werkzeuge stillschweigend fehlschlagende Suchen erlauben, wobei die Suchmuster zur Angabe von Dokumentation benutzt werden.

Migrationshinweis: Ein Fehler in Debhelper 11 bis 11.1.5 führte fälschlicherweise dazu, dass dh_installinfo --sourcedir ingorierte.

Beachten Sie, dass dieses Element eventuell hinfällig wird, da die Ursprungsautoren beabsichtigen, die Unterstützung für die Umgebungsvariable PERL_USE_UNSAFE_INC einzustellen. Wenn Perl die Unterstützung dafür einstellt, wird diese Variable nachträglich auch aus bestehenden Kompatibilitätsstufen entfernt.

Beachten Sie, dass diese Änderung nicht für dieses Quellpaket relevant 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 Pakete -doc-Pakete 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. D.h. 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 ein 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, z.B. wie im folgenden Beispiel:

    override_dh_auto_configure:
        dh_auto_configure -- --libexecdir=/usr/libexec

Beachten Sie das -- vor dem Parameter --libexecdir.

Falls Sie etwas haben, was dh_installinit außer Kraft setzt (z.B. um es mit --no-start aufzurufen), dann werden Sie wahrscheinlich auch etwas 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.

Dies ist der empfohlene Betriebsmodus.

Änderungen gegenüber v12 sind:

This feature changed between between debhelper 13 and debhelper 13.2.

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 außer Kraft setzenden Ziel in der Datei debian/rules oder dem passenden Paket erledigen. Zum Beispiel:

    # Disable dh_missing
    override_dh_missing:

Note that dh_installtmpfiles responds to debian/package.tmpfiles where dh_installsystemd used a name without the trailing "s".

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 erfolgt als Teil der Funktionen filearray und filedoublearray.

Alle Pakete, die sich darauf verlassen, dass diese Ziele immer ausgeführt werden, sollten maßgebliche 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 ...

Changes from v13 are:

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 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.

ANMERKUNGEN

Unterstützung mehrerer Binärpakete
Falls Ihr Quellpaket mehr als ein Binärpaket erzeugt, werden Debhelper-Programme standardmäßig bei der Ausführung auf alle Paketen einwirken. Falls es vorkommt, dass Ihr Quellpaket ein architekturabhängiges Paket und ein anderes architekturunabhängiges Paket erzeugt, ist dies nicht das korrekte Verhalten, da Sie die architekturabhängigen Pakete im debian/rules-Ziel »binary-arch« erzeugen müssen und die unabhängigen Pakete im debian/rules-Ziel »binary-indep«.

Um dies zu erleichtern sowie Ihnen mehr Kontrolle darüber zu geben, auf welche Pakete Debhelper-Programme einwirken, akzeptieren alle Debhelper-Programme die Parameter -a, -i, -p und -s. Diese Parameter sind kumulativ. Falls keiner angegeben wurde, wirken Debhelper-Programme standardmäßig auf alle Paketen ein, die in der Datei »control« aufgeführt sind, mit nachfolgenden Ausnahmen.

Zuerst werden alle Pakete, deren Architecture-Feld in debian/control nicht mit der DEB_HOST_ARCH -Architektur übereinstimmt, ausgeschlossen ("Debian Policy, Abschnitt 5.6.8").

Außerdem können einige zusätzliche Paket basierend auf dem Inhalt der Umgebungsvariable DEB_BUILD_PROFILES und den Feldern Build-Profiles in den Absätzen für binäre Pakete in debian/control ausgeschlossen werden. Dies geschieht gemäß der Entwurfrichtlinie unter <https://wiki.debian.org/BuildProfileSpec>;.

Zusammenspiel zwischen Paketauswahl und Bauprofilen

Bauprofile beeinflussen, welche Pakete im Paketauswahlmechanismus von Debhelper enthalten sind. Im Allgemeinen wird die Paketauswahl unter der Annahme beschrieben, dass alle Pakete aktiviert sind. Dieser Abschnitt beschreibt wie die Auswahl reagiert, wenn ein Paket aufgrund des aktiven Bauprofils (oder das Fehlen des aktiven Bauprofils) deaktiviert wird.
-a/--arch, -i/--indep ODER keine Auswahloptionen (ein roher
»dh_X«-Aufruf)

Das durch Bauprofile deaktivierte Paket wird stillschweigend aus der Auswahl ausgeschlossen.

Beachten Sie, dass Sie eine Warnung bekommen, falls alle zu dieser Auswahl gehörenden Pakete deaktiviert werden. In diesem Fall ist der Bau im Allgemeinen überhaupt sinnlos.

-N Paket / --no-package Paket

Die Option wird akzeptiert und hat keine Wirkung.

-p Paket / --package Paket

Die Option wird akzeptiert, aber Debhelper wird nichts an dem Paket vornehmen.

Beachten Sie, dass es keine Rolle spielt, ob das Paket standardmäßig aktiviert oder deaktiviert ist.

Automatisches Erzeugen von Debian-Installationsskripten
Einige Debhelper-Befehle werden automatisch Teile der Debian-Betreuerskripte erzeugen. Falls Sie diese automatisch erzeugten Dinge in Ihre existierenden Debian-Betreuerskripte einfügen möchten, dann müssen Sie Ihren Skripten #DEBHELPER# an der Stelle hinzufügen, an die der Kode hinzugefügt werden soll. #DEBHELPER# wird bei der Ausführung durch irgendeinen automatisch erzeugten Kode ersetzt.

Falls ein Skript überhaupt noch nicht existiert und Debhelper etwas darin hinzufügen muss, dann wird Debhelper das komplette Skript erstellen.

Alle Debhelper-Befehle, die auf diese Art automatisch Kode erzeugen, lassen dies durch den Parameter -n deaktiviert (siehe oben).

Beachten Sie, dass der eingefügte Kode Shell-Kode sein wird. Sie können ihn daher nicht direkt in einem Perl-Skript verwenden. Falls Sie ihn in ein Perl-Skript einbetten wollen, wird hier eine Möglichkeit beschrieben, dies zu tun (beachten Sie, dass über den Befehl »set« sichergestellt wird, dass $1, $2, etc. gesetzt sind):

  my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
  #DEBHELPER#
  EOF
  if (system($temp)) {
     my $exit_code = ($? >> 8) & 0xff;
     my $signal = $? & 0x7f;
     if ($exit_code) {
         die("Das Debhelper-Skript scheiterte mit folgendem Fehlercode: ${exit_code}");
     } else {
         die("Das Debhelper-Skript wurde per Signal abgebrochen: ${signal}");
     }
  }

Automatisches Erzeugen verschiedener Abhängigkeiten
Einige Debhelper-Befehle könnten dazu führen, dass das erzeugte Paket von einigen anderen Paketen abhängt. Falls Sie beispielsweise dh_installdebconf(1) benutzen, wird Ihr Paket von Debconf abhängen müssen. Oder, falls Sie dh_installxfonts(1) verwenden, wird ihr Paket generell von einer bestimmten Version der Xutils abhängen. Den Überblick über diese verschiedenen Abhängigkeiten zu behalten kann lästig sein, da sie davon abhängen, wie Debhelper Dinge tut, weswegen Debhelper eine Möglichkeit bietet, sie zu automatisieren.

Für jeden Befehl werden die benötigten Abhängigkeiten in den Handbuchseiten dokumentiert. Daneben wird automatisch eine »substvar« erzeugt, die ${misc:Depends} genannt wird. Falls Sie eine Markierung in Ihre debian/control-Datei schreiben, wird es sie zu den Abhängigkeiten expandieren, von denen Debhelper findet, dass Sie sie benötigen.

Dies ist gänzlich unabhängig von dem vorgegebenen ${shlibs:Depends}, das durch dh_makeshlibs(1) erzeugt wurde und den durch dh_perl(1) erzeugten ${perl:Depends}. Sie können auswählen, keines davon zu benutzen, falls die Einschätzung von Debhelper nicht der Wirklichkeit entspricht.

Paketbauverzeichnisse
Standardmäßig gehen alle Debhelper-Programme davon aus, dass das temporäre Verzeichnis, das zum Zusammenbau des Dateibaums in einem Paket benutzt wird, debian/Paket ist.

Manchmal wollen Sie möglicherweise ein anderes temporäres Vezeichnis benutzen. Dies wird durch den Schalters -P unterstützt. »dh_installdocs -Pdebian/tmp« wird zum Beispiel debian/tmp als temporäres Verzeichnis nutzen. Beachten Sie, falls Sie -P verwenden, dass die Debhelper-Programme nur auf ein einzelnes Paket auf einmal einwirken kann. Falls Sie also ein Paket haben, das mehrere Binärpakete baut, müssen Sie außerdem den Schalter -p einsetzen, um anzugeben, auf welches Binärpaket sich das Debhelper-Programm auswirkt.

Udebs
Debhelper beinhaltet Unterstützung für Udebs. Um ein Udeb mit Debhelper zu erstellen, fügen Sie dem Absatz des Pakets in debian/control »Package-Type: udeb« hinzu. Debhelper wird versuchen, Udebs zu erstellen, die der Debian-Installer-Richtlinie entsprechen, indem die erzeugten Paketdateien mit .udeb enden, indem keine Dokumentation in ein Udeb installiert wird und indem preinst-, postrm-, prerm- und config-Skripte etc. übersprungen werden.

UMGEBUNGSVARIABLEN

This section describes some of the environment variables that influences the behaviour of debhelper or which debhelper interacts with.

It is important to note that these must be actual environment variables in order to affect the behaviour of debhelper (not simply Makefile variables). To specify them properly in debian/rules, be sure to "export" them. For example, "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 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 irgendwelchen 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, auf den die Variable gesetzt ist, den -X-Optionen aller Befehle hinzu, die die Option -X unterstützen. Außerdem wird dh_builddeb für alles, das dem Wert in Ihrem Paketbaubaum entspricht, rm -rf ausführen.

Dies kann nützlich sein, falls Sie aus einem CVS-Quellverzeichnisbaum bauen. In diesem Fall verhindert das Setzen von DH_ALWAYS_EXCLUDE=CVS, dass irgendwelche CVS-Verzeichnisse sich in das Paket einschleichen, das Sie bauen. Oder, falls ein Paket einen Quell-Tarball hat, der (unklugerweise) CVS-Verzeichnisse enthält, möchten Sie möglicherweise DH_ALWAYS_EXCLUDE=CVS in debian/rules exportieren, damit es wirksam ist, wo auch immer Ihr Paket gebaut wird.

Mehrere Dinge, die ausgeschlossen werden sollen, können mit Doppelpunkten getrennt werden, wie in DH_ALWAYS_EXCLUDE=CVS:.svn.

DH_EXTRA_ADDONS

Falls gesetzt, fügt dies die angegebenen Dh-Erweiterungen hinzu, die an den entsprechenden Stellen in den Sequenzen von Befehlen 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 eine Debhelper-Erweiterung benötigen, während mehrfachem Bauen ausgeführt werden, ohne ein große Anzahl von Dateien ausbessern zu müssen. 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 dieselben Farbeinstellungen für Dpkg und Debhelper benutzen wollen. In dem unwahrscheinlichen Fall, dass Sie für Debhelper andere Farbeinstellungen möchten, können Sie DH_COLORS statt oder zusätzlich zu DPKG_COLORS verwenden.

NO_COLOR

Falls nicht explizit um Farbe gebeten wurde (z.B. sowohl DH_COLORS als auch DPKG_COLORS sind nicht gesetzt), führt das Vorliegen 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 die Funktionalität von dpkg-buildflags(1), um dies zu tun (z.B. DEB_BUILD_MAINT_OPTIONS=hardening=all oder DEB_CPPFLAGS_MAINT_APPEND=-DCUSTOM_MACRO=true), anstatt die konkrete Variable direkt zu setzen.

HOME , XDG_*

In compat 13 and later, these environment variables are reset before invoking the upstream build system via the dh_auto_* helpers. The variables HOME (all dh_auto_* helpers)and XDG_RUNTIME_DIR (dh_auto_test only) will be set to a writable directory. All remaining variables and XDG_RUNTIME_DIR (except for during dh_auto_test) will be cleared.

The HOME directory will be created as an empty directory but it will be reused between calls to dh_auto_*. Any content will persist until explicitly deleted or dh_clean.

DEB_BUILD_OPTIONS

Please see "Supported flags in DEB_BUILD_OPTIONS" for this environment variable.

Please note that this variable should not be altered by package maintainers inside debian/rules to change the behaviour of debhelper. Instead, where the package maintainer need these features, they should look disabling the relevant feature directly (e.g. by overriding the concrete tools).

DEB_MAINT_BUILD_OPTIONS

This is a dpkg specific environment variable (see e.g. dpkg-buildflags(1)). The debhelper tool suite silently ignores it.

It is documented here because it has a similar name to DEB_BUILD_OPTIONS , which make some people mistakenly assume that debhelper will also react to this variable.

Supported flags in DEB_BUILD_OPTIONS
The debhelper tool suite reacts to the following flags in DEB_BUILD_OPTIONS .
dherroron=obsolete-compat-levels

This is a debhelper specific value.

When dherroron is present and set to obsolete-compat-levels, then debhelper tools will promote deprecation warnings for usage of old soon to be removed compat levels into errors.

This is useful for automated checking for code relying on deprecated compat levels that is scheduled for removal.

This option is intended for testing purposes; not production builds.

nostrip

This value will change the content of the debs being built. The .deb packages built when this is set is therefore not bit-for-bit reproducible with a regular build in the general case.

This value will cause the official debhelper tools will skip actions and helpers that either remove, detach or deduplicate debugging symbols in ELF binaries.

This value affects dh_dwz(1) and dh_strip(1).

nocheck

This value will cause the official debhelper build systems to skip runs of upstream test suites.

Package maintainers looking to avoid running the upstream tests should not rely on this. Instead, they can add an empty override target to skip dh_auto_test.

This value affects dh_auto_test(1).

nodoc

This value will change the content of the debs being built. The .deb packages built when this is set is therefore not bit-for-bit reproducible with a regular build in the general case.

This value will cause several debhelper tools to skip installation of documentation such as manpages or upstream provided documentation. Additionally, the tools will also ignore if declared documentation is "missing" on the assumption that the documentation has not been built.

This value effects tools like dh_installdocs(1), which knows it is working with documentation.

noautodbgsym, noddebs

The official name is autodbgsym. The noddebs variant is accepted for historical reasons.

This value causes debhelper to skip the generation of automatically generated debug symbol packages.

This value affects dh_strip(1).

parallel=N

This value enables debhelper to use up to N threads or processes (subject to parameters like --no-parallel and --max-parallel=M). Not all debhelper tools work with parallel tasks and may silently ignore the request.

This value affects many debhelper tools. Most notably dh_auto_*, which will attempt to run the underlying upstream build system with that number of threads.

terse

This value will cause the official debhelper build systems to configure upstream builds to be terse (i.e. reduce verbosity in their output). This is subject to the upstream and the debhelper build system supporting such features.

This value affects most dh_auto_* tools.

Unknown flags are silently ignored.

Note third-party debhelper-like tools or third-party provided build systems may or may not react to the above flags. This tends to depend on implementation details of the tool.

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 [AT] vollbio.de und das deutsche Debian-Übersetzer-Team im Dezember 2011 erstellt.

Bitte melden Sie alle Fehler in der Übersetzung an debian-l10n-german [AT] lists.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 [AT] debian.org>