Provided by: debhelper_12.10ubuntu1_all bug

NAME

       debhelper - die Debhelper-Werkzeugsammlung

ÜBERSICHT

       dh_* [-v] [-a] [-i] [--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.

       Wo das Werkzeug es nicht ausdrücklich anders kennzeichnet, gehen alle Debhelper-Werkzeuge davon aus, dass
       sie aus dem Wurzelverzeichnis eines entpackten Quellpakets ausgeführt werden. Dadurch können Sie dann,
       wenn notwendig, Dateien wie debian/control finden.

DEBHELPER-BEFEHLE

       Hier ist die Liste der Debhelper-Befehle, die Sie benutzen können. Zusätzliche Dokumentation finden Sie
       in deren Handbuchseiten.

       dh_auto_build(1)
           baut ein Paket automatisch

       dh_auto_clean(1)
           räumt nach dem Bauen automatisch auf

       dh_auto_configure(1)
           konfiguriert das Paket automatisch vor dem Bauen.

       dh_auto_install(1)
           führt »make install« oder Ähnliches aus

       dh_auto_test(1)
           führt automatisch die Test-Suites eines 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 Links in Bauverzeichnissen von Paketen

       dh_dwz(1)
           optimiert DWARF-Fehlersuchinformationen in ELF-Binärdateien über dwz

       dh_fixperms(1)
           korrigiert Zugriffsrechte von Dateien in Bauverzeichnissen

       dh_gencontrol(1)
           erzeugt und installiert die 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 Changelogs in die Paketbauverzeichnisse

       dh_installcron(1)
           installiert Cron-Skripte in etc/cron.*

       dh_installdeb(1)
           installiert Dateien in das Verzeichnis DEBIAN.

       dh_installdebconf(1)
           installiert Dateien, die von Debconf im Paketbauverzeichnis benutzt werden

       dh_installdirs(1)
           erstellt Unterverzeichnisse in den Paketbauverzeichnissen

       dh_installdocs(1)
           installiert Dokumentation in Paketbauverzeichnisse

       dh_installemacsen(1)
           registriert ein Emacs-Add-on-Paket

       dh_installexamples(1)
           installiert Beispieldateien in die Paketbauverzeichnisse.

       dh_installifupdown(1)
           installiert »if-up«- und »if-down«-Hooks.

       dh_installinfo(1)
           installiert Info-Dateien

       dh_installinit(1)
           installiert Dienstinitialisierungsdateien in Paketbauverzeichnisse

       dh_installinitramfs(1)
           installiert Initramfs-Hooks und Einrichtungsverwaltungsskripte

       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 Fenstermanager

       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_strip(1)
           entfernt Symbole aus Programmen, gemeinsam benutzten Bibliotheken und einigen statischen Bibliotheken

       dh_systemd_enable(1)
           aktiviert/deaktiviert Systemd-Unit-Dateien

       dh_systemd_start(1)
           startet/stoppt oder startet Systemd-Unit-Dateien erneut

       dh_testdir(1)
           Verzeichnis vor dem Bauen des Debian-Pakets testen

       dh_testroot(1)
           stellt sicher, dass ein Paket mit der notwendigen Stufe von Root-Rechten gebaut wird.

       dh_usrlocal(1)
           migriert usr/local-Verzeichnisse zu Betreuerskripten

   Missbilligte Befehle
       Ein paar Debhelper-Befehle sind veraltet und sollten nicht benutzt werden.

       dh_gconf(1)
           installiert Standard-GConf-Dateien und registriert Schemen (missbilligt)

       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  Kompatibilitätsstufe  13  und  neuer  ist  es  möglich,  einfache  Ersetzungen  in einigen Debhelper-
       Konfigurationsdateien zu benutzen (insbesondere in Konfigurationsdateien für dh_install(1)).

       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:

       •   Die ausführbare Konfigurationsdatei muss erfolgreich enden (d.h. der Rückgabewert sollte einen Erfolg
           anzeigen).

       •   Auf  Kompatibilitätsstufen  über  13  unterliegt  die  Ausgabe  Ersetzungen  (siehe  "Ersetzungen  in
           Debhelper-Konfigurationsdateien"), wenn das Werkzeug diese unterstützt. Denken Sie  daran,  dass  Sie
           vorsichtig  sein  müssen,  falls  Ihr  Generator  auch Ersetzungen bereitstellt, da dies zu unnötiger
           Verwirrung führen kann.

           Andernfalls wird die Ausgabe exakt so benutzt, wie sie ist. Insbesondere wird  Debhelper  Platzhalter
           nicht expandieren oder Kommentare und Leerzeichen aus der Ausgabe entfernen.

       Falls  Sie  das  Paket  auf  einem  Dateisystem  bauen, auf dem Sie das Ausführungsbit nicht deaktivieren
       können, können Sie dh-exec(1) und sein Skript strip-output verwenden.

GEMEINSAM BENUTZTE DEBHELPER-OPTIONEN

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

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

       --no-act
           tut nicht wirklich etwas. Falls es 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.

       -n  verändert keine postinst-, postrm- etc. Skripte

       -XElement, --exclude=Element
           schließt ein Element von der Verarbeitung aus. Diese Option kann mehrfach benutzt werden, um mehr als
           nur  eins  auszuschließen. Das <Element> ist üblicherweise Teil eines Dateinamens und jede Datei, die
           den angegebenen Text enthält, wird ausgeschlossen.

       -A, --all
           bewirkt, dass Dateien oder andere Elemente, die auf der Befehlszeile angegeben wurden, sich in  ALLEN
           entsprechenden Paketen auswirken, nicht nur im ersten.

BAUSYSTEMOPTIONEN

       Die  folgenden  Befehlszeilenoptionen  werden von allen dh_auto_*-Debhelper-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.

       -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 v12 zu benutzen,
       stellen Sie sicher, dass debian/control Folgendes enthält:

         Build-Depends: debhelper-compat (>= 12)

       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 12 in debian/compat angeben, sicherstellen, dass debian/control Folgendes enthält:

         Build-Depends: debhelper (>= 12~)

       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:

       v5  Dies ist die unterste unterstützte Kompatibilitätsstufe.

           Falls Sie ein Upgrade von einer vorhergehenden Kompatibilitätsstufe durchführen, überprüfen Sie bitte
           debhelper-obsolete-compat(7).

           Dieser Modus ist missbilligt.

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

           Dieser Modus ist missbilligt.

       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 Changelog der Originalautoren
                   liegt, falls keines angegeben wurde.

           Dieser Modus ist missbilligt.

       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 dpkg-gensymbols Bibliotheken an unüblichen Orten übergeben, die es ansonsten
                   nicht verarbeiten würde. Solche Verhaltensänderung kann den Bau einiger Pakete zum  Scheitern
                   bringen.

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

           Dieser Modus ist missbilligt.

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

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

           -       Alle  dh_auto_*-Debhelper-Programme  und  dh  setzen  Umgebungsvariablen,  die  durch   dpkg-
                   buildflags aufgelistet werden, sofern 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 Fehlersuchsymbole an einer  Stelle  ab,  die  auf  ihrer  Baukennzahl
                   basiert.

           -       Ausführbare  Debhelper-Konfigurationsdateien  werden  ausgeführt  und  ihre  Ausgabe wird als
                   Konfiguration benutzt.

       v10 Ä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_installdeb installiert keine vom Paketbetreuer  bereitgestellte  debian/Paket.shlibs-Datei
                   mehr. Dies wird stattdessen von dh_makeshlibs erledigt.

           -       dh_installwm  weigert  sich,  ein  beschädigtes 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.

           -       Der  Befehl  dh  wird  keinen  der  veralteten  Parameter  zur  »manuellen  Sequenzsteuerung«
                   (--before, --after, etc.) akzeptieren. Bitte verwenden Sie stattdessen Aufhebungsziele.

                   Nachträglich  auf frühere Kompatibilitätsstufen angewandt:  dh akzeptiert seit Debhelper/12.4
                   nichts davon mehr.

           -       Der  Befehl  dh  wird  zur  Verfolgung,  welche  Befehle  ausgeführt  wurden,  nicht   länger
                   Protokolldateien  benutzen. Der Befehl dh verfolgt weiterhin, ob die »Bau«-Sequenz ausgeführt
                   wurde und überspringt sie in diesem Fall.

                   Die wichtigsten Auswirkungen davon sind:

                   -   Hierdurch wird die Fehlersuche bei den Sequenzen install und/oder  binary  einfacher,  da
                       sie  nun  einfach erneut ausgeführt werden können (ohne, dass ein vollständiger »Aufräum-
                       und Neubau«-Durchgang erforderlich ist).

                   -   Der Pferdefuss hier liegt darin, dass dh_*  nun  nur  noch  nachverfolgt,  was  in  einem
                       einzelnen  außer  Kraft  setzenden  Ziel  geschieht.  Wenn alle Aufrufe eines angegebenen
                       dh_cmd-Befehls im selben außer Kraft setzenden Ziel stattfinden,  wird  alles  wie  zuvor
                       funktionieren.

                       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.

           -       Der Befehl dh_installdeb maskiert nun die Zeilen in der Konfigurationsdatei maintscript   für
                   die Shell. Dies war der ursprüngliche Gedanke, aber es funktionierte nicht, wie es sollte und
                   die  Pakete  begannen,  sich  auf  die  unvollständige  Shell-Maskierung  zu  verlassen (z.B.
                   Dateinamen in Anführungszeichen setzen).

           -       Voreinstellung für den Befehl dh_installinit ist nun --restart-after-upgrade.  Verwenden  Sie
                   bitte für Pakete, die das vorhergehende Verhalten erfordern, --no-restart-after-upgrade.

           -       Die  autoreconf-Sequenz  ist  nun  standardmäßig  aktiviert.  Bitte  übergeben  Sie --without
                   autoreconf an dh, falls dies für ein angegebenes Paket nicht gewünscht wird.

           -       Die systemd-Sequenz ist nun standardmäßig aktiviert. Bitte übergeben Sie --without systemd an
                   dh, falls dies für ein angegebenes Paket nicht gewünscht wird.

           -       Nachträglich entfernt: dh erstellt  das  Bauverzeichnis  des  Pakets  nicht  mehr,  wenn  die
                   Ausführung  von Debhelper-Befehlen übersprungen wird. Dies hat keine Auswirkungen auf Pakete,
                   die nur mit Debhelper-Befehlen bauen, es könnte aber Fehler in Befehlen offenlegen, die nicht
                   in Debhelper enthalten sind.

                   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.

       v11 Von diesem Modus wird abgeraten.

           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:

           -       dh_installinit  installiert  keine service- oder tmpfile-Dateien mehr. Es erstellt auch keine
                   Betreuerskripte dafür. Bitte verwenden Sie das neue Hilfsprogramm dh_installsystemd.

           -       Die Hilfsprogramme dh_systemd_enable und dh_systemd_start wurden durch das neue Hilfsprogramm
                   dh_installsystemd ersetzt.  Aus  demselben  Grund  wurde  auch  die  systemd-Sequenz  für  dh
                   entfernt.  Wenn  Sie  das Hilfswerkzeug dh_installsystemd deaktivieren möchten, verwenden Sie
                   bitte ein leeres außer Kraft setzendes Ziel.

                   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.

           -       dh_installdirs  erstellt  keine  debian/Paket-Verzeichnisse  mehr,  es  sei  denn,  dies wird
                   ausdrücklich verlangt (oder es muss ein Unterverzeichnis darin erstellt werden).

                   Die große Mehrheit aller Pakete wird von dieser Änderung nicht betroffen sein.

           -       Das makefile-Bausystem übergibt nun INSTALL="install --strip-program=true" an make(1).  Davon
                   abgeleitete Bausysteme (z.B. configure oder cmake) sind von dieser Änderung nicht betroffen.

           -       Das autoconf-Bausystem übergibt nun --runstatedir=/run an ./configure.

           -       Das cmake-Bausystem übergibt nun -DCMAKE_INSTALL_RUNSTATEDIR=/run an cmake(1).

           -       dh_installman  wird  nun vorzugsweise die Sprache anhand des Pfadnamens statt der Erweiterung
                   bestimmen.

           -       dh_auto_install wird nun nur das Zielverzeichnis erstellen, das es benötigt. Vorher hätte  es
                   die  Bauverzeichnisse  für  alle Pakete erstellt. Dies hat keine Auswirkungen auf Pakete, die
                   nur mit Debhelper-Befehlen bauen, es könnte aber Fehler in Befehlen offenlegen, die nicht  in
                   Debhelper enthalten sind.

           -       Die Hilfsprogramme dh_installdocs, dh_installexamples, dh_installinfo und dh_installman geben
                   nun  Fehlermeldungen  aus,  falls ihre Konfiguration ein Muster aufweist, das zu nichts passt
                   oder sich auf einen Pfad bezieht, den es nicht gibt.

                   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.

           -       Die  Hilfsprogramme  dh_installdocs,  dh_installexamples,  dh_installinfo  und  dh_installman
                   akzeptieren  nun  den  Parameter  --sourcedir  mit  derselben  Bedeutung  wie für dh_install.
                   Überdies fallen sie nun auch auf debian/tmp wie dh_install zurück.

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

           -       Die  Bausysteme  perl-makemaker  und perl-build übergeben nicht mehr -I. an Perl. Pakete, die
                   dieses Verhalten immer noch benötigen,  können  es  durch  Verwendung  der  Umgebungsvariable
                   PERL5LIB  emulieren, z.B. durch Hinzufügen von export PERL5LIB=. in ihre »debian/rules«-Datei
                   (oder dergleichen).

           -       Die  Umgebungsvariable  PERL_USE_UNSAFE_INC  wird  nicht  mehr  durch  dh   oder   eins   der
                   dh_auto_*-Werkzeuge  gesetzt.  Sie  wurde  vorübergehend  als  Behelfslösung  gesetzt,  um zu
                   verhindern, dass das gleichzeitige Bauen vieler Pakete scheitert.

                   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.

           -       Das Hilfsprogramm dh_makeshlibs wird nun mit einer Fehlermeldung beendet, falls Objdump einen
                   Rückgabewert ungleich Null von der Auswertung einer übergebenen Datei zurückgibt.

           -       Die  Werkzeuge  dh_installdocs  und  dh_installexamples  installieren  nun möglicherweise die
                   meiste Dokumentation in einem anderen Pfad, um die Empfehlung  der  Debian-Richtlinien  §12.3
                   (seit Version 3.9.7) zu erfüllen.

                   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.

           -       Die  Werkzeuge  dh_strip  und  dh_shlibdeps  verwenden  keine  Dateinamenmuster  mehr,  um zu
                   bestimmen, welche Dateien verarbeitet werden. Stattdessen öffnen sie die  Datei  und  schauen
                   nach  einem  ELF-Header,  um  zu  bestimmen, ob eine übergebene Datei ein gemeinsam benutztes
                   Objekt oder ein ausführbares binäres Programm ist.

                   Diese Änderung kann dazu führen, dass mehr Dateien als vorher verarbeitet werden.

       v12 Dies ist der empfohlene Betriebsmodus.

           Änderungen gegenüber v11 sind:

           -       Das  Werkzeug  dh_makeshlibs  erzeugt  nun  standardmäßig  Shlibs-Dateien  mit  versionierter
                   Abhängigkeit. Dies bedeutet, dass -VUpstream-Version (alias -V) nun die Voreinstellung ist.

                   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.

           -       Die Option -s (--same-arch) wurde entfernt. Bitte verwenden Sie stattdessen -a (--arch).

           -       Der  Aufruf  von  dh_clean  -k  verursacht  jetzt  einen  Fehler  statt einer Warnung, es sei
                   missbilligt.

           -       Die Option --no-restart-on-upgrade in dh_installinit wurde entfernt. Bitte verwenden Sie  den
                   neuen Namen --no-stop-on-upgrade.

           -       Es gab einen Fehler in den doit-Funktionen (und ähnlichen) von Debian::Debhelper::Dh_Lib, der
                   unter  einem  bestimmten  Umstand  zum  Öffnen  einer  Shell  führte. Dieser Fehler wurde nun
                   entfernt, wodurch Hilfsprogramme, die auf den Fehler setzen, mit  der  Meldung  »command  not
                   found« fehlschlagen.

           -       --list-missing  und  --fail-missing  in  dh_install  wurden  entfernt.  Bitte  verwenden  Sie
                   dh_missing und die zugehörigen Optionen, die die durch  andere  Hilfsprogramme  installierten
                   Dateien ebenfalls sehen können.

           -       Das Hilfsprogramm dh_installinit installiert nicht mehr die Konfiguration für das Init-System
                   Upstart.  Stattdessen  bricht  es das Bauen ab, wenn es eine alte Upstart-Konfigurationsdatei
                   findet. Der Fehler ist dort, um den Paketbetreuer daran zu erinnern,  dass  er  sicherstellt,
                   die  mit vorherigen Versionen des Pakets mitgelieferten Conffiles (falls vorhanden) sauber zu
                   entfernen.

           -       Das Werkzeug dh_installdeb wird die Grundprüfung  einiger  dpkg-maintscript-helper(1)-Befehle
                   durchführen und eine Fehlermeldung ausgeben, falls die Befehle ungültig zu sein scheinen.

           -       Das Werkzeug dh_missing wird nun auf --list-missing voreingestellt.

           -       Das  Werkzeug  dh_makeshlibs wird nun nur Bibliotheken an dpkg-gensymbols(1) übergeben, falls
                   die ELF-Binärdatei einen SONAME hat (enthält ».so«).

           -       Das  Werkzeug  dh_compress  komprimiert   keine   Beispiele   mehr   (d.h.   alles   was   in
                   </usr/share/doc/Paket/examples> installiert ist.)

           -       Die  Standardsequenz  in  dh  enthält  nun standardmäßig dh_dwz und dh_installinitramfs. Dies
                   macht die Sequenzen dwz und installinitramfs überflüssig. Sie werden  nun  mit  einem  Fehler
                   scheitern. Falls Sie diese Befehl überspringen wollen, fügen Sie bitte ein leeres außer Kraft
                   setzendes Ziel in debian/rules ein (z.B. override_dh_dwz:).

           -       Die  Bausysteme  Meson  und Autoconf setzen die Variable --libexecdir nicht mehr explizit und
                   verlassen sich daher auf die Voreinstellung des Bausystems, die /usr/libexec sein sollte (per
                   FHS 3.0, angenommen in der Debian-Richtlinie 4.1.5).

                   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.

           -       Das Werkzeug dh_installdeb installiert  nicht  mehr  die  vom  Paketbetreuer  bereitgestellte
                   conffiles-Datei.   Die   Datei   war  seit  Kompatibilitätsstufe  3  meist  überflüssig,  als
                   dh_installdeb  anfing,  die  resultierende  conffiles-Steuerdatei   automatisch   selbst   zu
                   berechnen.

           -       Das  Werkzeug  dh_installsystemd  beruht nicht mehr auf dh_installinit, um Systemd-Dienste zu
                   handhaben, die über eine SysVinit-Alternative verfügen. Beide Werkzeuge müssen nun  in  einem
                   solchen  Fall  benutzt  werden, um sicherzustellen, dass der Dienst sowohl unter SysVinit als
                   auch unter Systemd sauber gestartet wird.

                   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.

           -       Das  Drittherstellerwerkzeug dh_golang (aus dem Paket dh-golang) akzeptiert nun standardmäßig
                   die Variable DH_GOLANG_EXCLUDES für die Quelleninstallation in  -dev-Paketen  und  nicht  nur
                   während  des  Bauprozesses.  Bitte  setzen  Sie  DH_GOLANG_EXCLUDES_ALL  auf  »false«, um zum
                   vorherigen  Verhalten  zurückzukehren.  Einzelheiten   und   Beispiele   finden   Sie   unter
                   Debian::Debhelper::Buildsystem::golang(3pm).

           -       dh_installsystemduser ist nun per Voreinstellung in der Standard-dh-Sequenz enthalten.

           -       Das  Bausystem  python-distutils  wurde  nun  entfernt.  Bitte  verwenden Sie stattdessen das
                   Drittanbieterbausystem pybuild.

       v13 Diese Kompatibilitätsstufe ist immer noch für die Entwicklung offen. Verwenden Sie sie mit Vorsicht.

           Änderungen gegenüber v12 sind:

           -       Das Bausystem meson+ninja benutzt nun meson test anstelle von ninja test, wenn die  Testsuite
                   ausgeführt  wird.  Alles, was dh_auto_test außer Kraft setzt und zusätzliche Parameter an das
                   Testausführungsprogramm der Ursprungsautoren übergibt, sollte überprüft werden, da meson test
                   auf der Befehlszeile nicht mit ninja test kompatibel ist.

           -       Alle Debhelper-ähnlichen Werkzeuge, die auf  der  offiziellen  Debhelper-Bibliothek  basieren
                   (einschließlich  dh  und  den  offiziellen  dh_*-Werkzeugen)  akzeptieren  keine  abgekürzten
                   Befehlsparameter   mehr.   Gleichzeitig   sortiert   dh   nun   Aufrufe   zu    überflüssigen
                   dh_*-Hilfsprogrammen sogar dann aus, wenn lange Befehlszeilenoptionen angegeben werden.

           -       Die  ELF-bezogenen Debhelper-Werkzeuge (dh_dwz, dh_strip, dh_makeshlibs, dh_shlibdeps) werden
                   nun standardmäßig nur noch für architekturabhängige Pakete ausgeführt (d.h.  sie  werden  von
                   *-indep-Zielen  ausgeschlossen  und  standardmäßig  mit  -a  übergeben).  Falls  Sie  sie für
                   *-indep-Ziele benötigen, können Sie eine  explizite  Build-Depends  in  dh-sequence-elf-tools
                   hinzufügen.

           -       Das  Drittanbieterbausystem gradle (aus dem Paket gradle-debian-helper) führt nun automatisch
                   eine von den Ursprungsautoren bereitgestellte Testsuite aus. Setzen  Sie  dh_auto_test  außer
                   Kraft, um dieses Verhalten zu unterbinden.

           -       Das Werkzeug dh_installman beendet sich vorzeitig, falls es sich widersprechende Definitionen
                   einer   Handbuchseite  entdeckt.  Dies  geschieht  normalerweise,  falls  das  Bausystem  der
                   Ursprungsautoren eine komprimierte Version installiert und das Paket eine nicht  komprimierte
                   Version  der  Handbuchseite  in  debian/package.manpages  auflistet. Meist ist die einfachste
                   Lösung, die Handbuchseite aus debian/package.manpages zu  entfernen  (davon  ausgehend,  dass
                   beide Versionen identisch sind).

           -       Die  dh_auto_*-Hilfsprogramme  setzen  nun  die  Umgebungsvariablen  HOME  und  gebräuchliche
                   XDG_*-Variablen zurück. HOME und XDG_RUNTIME_DIR sind jeweils auf ein separates, schreibbares
                   Verzeichnis gesetzt. Die restlichen Umgebungsvariablen werden geleert.

           -       Der Befehl dh wird nun einen Fehler ausgeben, falls ein außer Kraft setzendes oder  Hook-Ziel
                   für einen veralteten Befehl in debian/rules (z.B. override_dh_systemd_enable:) vorhanden ist.

           -       Der  Befehl  dh_missing  wird nun auf --fail-missing voreingestellt. Dies kann zu einer nicht
                   fatalen Warnung zurück geändert werden, indem explizit --list-missing übergeben wird, wie  es
                   in Kompatibilitätsstufe 12 war.

                   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:

           -       Der  Befehlssequenzer  dh  führt  nun  in   der   Standardsequenz   dh_installtmpfiles   aus.
                   dh_installtmpfiles    übernimmt    die   Handhabung   von   tmpfiles.d-Konfigurationsdateien.
                   Diesbezügliche Funktionalität in dh_installsystemd ist nun deaktiviert.

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

           -       Viele dh_*-Werkzeuge unterstützen nun eingeschränkte Variablenexpandierung per ${foo}-Syntax.
                   In vielen  Fällen  kann  dies  benutzt  werden,  um  Pfade  zu  referenzieren,  die  entweder
                   Leerzeichen  oder dpkg-architecture(1)-Werte enthalten. Obwohl es den Bedarf an dh-exec(1) in
                   einigen Fällen vermindern kann, ist es im Allgemeinen kein Ersatz für dh-exec(1).  Falls  Sie
                   filtern, umbenennen usw. möchten, wird das Paket weiterhin dh-exec(1) benötigt.

                   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.

           -       Der Befehlssequenzer dh wird nun alle Hooks und außer Kraft setzenden Ziele für dh_auto_test,
                   dh_dwz   und    dh_strip    überspringen,    wenn    DEB_BUILD_OPTIONS    die    maßgeblichen
                   nocheck-/nostrip-Optionen aufführt.

                   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.

           -       The cmake buildsystem now passes -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON to cmake(1) to  speed
                   up  automatic  installation  process. If for some reason you need previous behavior, override
                   the flag:

                       dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...

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

       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  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  Kompatibilitätsstufe  13  und  neuer  werden  diese  Umgebungsvariable  zurückgesetzt,  bevor das
           Baussystem der Ursprungsautoren über die dh_auto_*-Hilfsprogramme aufgerufen wird. Die Variablen HOME
           und XDG_RUNTIME_DIR werden auf ein beschreibbares Verzeichnis gesetzt.  Die  verbleibenden  Variablen
           werden geleert.

           Die  Verzeichnisse  werden leer erzeugt, sie werden allerdings zwischen den dh_auto_*-Aufrufen weiter
           benutzt. Jeglicher Inhalt wird weiter bestehen, bis er explizit  gelöscht  oder  dh_clean  aufgerufen
           wird.

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>

12.10ubuntu1                                       2020-03-27                                       debhelper(7)