debhelper(7) | Debhelper | debhelper(7) |
debhelper - die Debhelper-Werkzeugsammlung
dh_* [-v] [-a] [-i] [--no-act] [-pPaket] [-NPaket] [-Ptemporäres_Verzeichnis]
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.
Except where tool explicitly denotes otherwise, all of the debhelper tools assumes that they run from root directory of an unpacked source package. This is so they can locate find files like debian/control when needed.
Hier ist die Liste der Debhelper-Befehle, die Sie benutzen können. Zusätzliche Dokumentation finden Sie in deren Handbuchseiten.
Ein paar Debhelper-Befehle sind veraltet und sollten nicht benutzt werden.
Falls ein Programmname mit dh_ beginnt und das Programm nicht auf obiger Liste steht, dann ist es nicht Teil des Debhelper-Pakets, sollte aber trotzdem wie die anderen auf dieser Seite beschriebenen Programme funktionieren.
Viele Debhelper-Befehle machen von den Dateien in debian/ Gebrauch, um zu steuern, was sie tun. Neben den üblichen debian/changelog und debian/control, die in allen Paketen enthalten sind, nicht nur in denen, die Debhelper benutzen, können einige zusätzliche Dateien verwandt werden, um das Verhalten bestimmter Debhelper-Befehle zu konfigurieren. Diese Dateien heißen üblicherweise debian/Paket.foo (wobei Paket natürlich durch das Paket ersetzt wird, auf das es sich auswirkt).
dh_installdocs benutzt beispielsweise Dateien mit dem Namen debian/package.docs, um die Dokumentationsdateien aufzulisten, die es installieren wird. 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.
Note for the first (or only) binary package listed in debian/control, debhelper will use debian/foo when there's no debian/package.foo file. However, it is often a good idea to keep the package. prefix as it is more explicit. The primary exception to this are files that debhelper by default installs in every binary package when it does not have a package prefix (such as debian/copyright or 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.
The syntax of these files is intentionally kept very simple to make them easy to read, understand, and modify.
If you need additional flexibility, many of the debhelper tools (e.g. dh_install(1)) support executing a config file as a script.
To use this feature, simply mark the config file as executable (e.g. chmod +x debian/package.install) and the tool will attempt to execute it and use the output of the script. In many cases, you can use dh-exec(1) as interpreter of the config file to retain most of the original syntax while getting the additional flexibility you need.
When using executable debhelper config files, please be aware of the following:
If you need the package to build on a file system where you cannot disable the executable bit, then you can use dh-exec(1) and its strip-output script.
Die folgenden Befehlszeilenoptionen werden von allen Debhelper-Programmen unterstützt.
This option is removed in compat 12.
Falls die Originalautoren zum Beispiel ein debian/init liefern, von dem Sie nicht wünschen, dass dh_installinit es installiert, benutzen Sie --ignore=debian/init
Die folgende Befehlszeile wird von einigen Debhelper-Programmen unterstützt. Eine vollständige Erklärung, was jede Option tut, finden Sie in den Handbuchseiten jedes einzelnen Programms.
Die folgenden Befehlszeilenoptionen werden von allen dh_auto_*-Debhelper-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.
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.
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).
Bemerkenswerterweise ist das Setzen des Maximums auf 1 tatsächlich dasselbe wie die Verwendung von --no-parallel.
From time to time, major non-backwards-compatible changes need to be made to debhelper, to keep it clean and well-designed as needs change and its author gains more experience. To prevent such major changes from breaking existing packages, the concept of debhelper compatibility levels was introduced. You must tell debhelper which compatibility level it should use, and it modifies its behavior in various ways.
In current debhelper, you can specify the compatibility level in debian/control by adding a Build-Depends on the debhelper-compat package. For example, to use v12 mode, ensure debian/control has:
Build-Depends: debhelper-compat (= 12)
This also serves as an appropriate versioned build dependency on a sufficient version of the debhelper package, so you do not need to specify a separate versioned build dependency on the debhelper package unless you need a specific point release of debhelper (such as for the introduction of a new feature or bugfix within a compatibility level).
Note that debhelper does not provide debhelper-compat for experimental or beta compatibility levels; packages experimenting with those compatibility levels should use debian/compat or DH_COMPAT.
Prior versions of debhelper required specifying the compatibility level in the file debian/compat, and current debhelper still supports this for backward compatibility, though a package may not specify a compatibility level via multiple methods at once. To use this method, debian/compat should contain the compatibility level as a single number, and no other content. If you specify the compatibility level by this method, your package will also need a versioned build dependency on a version of the debhelper package equal to (or greater than) the compatibility level your package uses. So, if you specify compatibility level 12 in debian/compat, ensure debian/control has:
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.
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 Abfolgeerweiterung unabhängig von der Kompatibilitätsstufe nicht 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.
This compatibility feature had a bug since its inception in debhelper/9.20130516 that made it fail to apply in compat 9 and earlier. As there has been no reports of issues caused by this bug in those ~5 years, this item have been removed rather than fixed.
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.
Migration note: A bug in debhelper 11 up to 11.1.5 made dh_installinfo incorrectly ignore --sourcedir.
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.
Note that if a given source package only contains a single binary package in debian/control or none of the packages are -doc packages, then this change is not relevant for that source package and you can skip to the next change.
By default, these tools will now attempt to determine a "main package for the documentation" (called a doc-main-package from here on) for every -doc package. If they find such a doc-main-package, they will now install the documentation into the path /usr/share/doc/doc-main-package in the given doc package. I.e. the path can change but the documentation is still shipped in the -doc package.
The --doc-main-package option can be used when the auto-detection is insufficient or to reset the path to its previous value if there is a reason to diverge from Debian policy recommendation.
Some documentation will not be affected by this change. These exceptions include the copyright file, changelog files, README.Debian, etc. These files will still be installed in the path /usr/share/doc/package.
Diese Änderung kann dazu führen, dass mehr Dateien als vorher verarbeitet werden.
Änderungen gegenüber v11 sind:
If an unversioned dependency in the shlibs file is wanted, this can be obtained by passing -VNone instead. However, please see dh_makeshlibs(1) for the caveat of unversioned dependencies.
If a particular upstream package does not use the correct default, the parameter can often be passed manually via dh_auto_configure(1). E.g. via the following example:
override_dh_auto_configure: dh_auto_configure -- --libexecdir=/usr/libexec
Note the -- before the --libexecdir parameter.
If you have an override for dh_installinit (e.g. to call it with --no-start) then you will probably need one for dh_installsystemd as well now.
This change makes dh_installinit inject a misc:Pre-Depends for init-system-helpers (>= 1.54~). Please ensure that the package lists ${misc:Pre-Depends} in its Pre-Depends field before upgrading to compat 12.
Changes from v12 are:
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.
Beachten Sie, dass Sie eine Warnung bekommen, falls alle zu dieser Auswahl gehörenden Pakete deaktiviert werden. In diesem Fall ist der Bau im Allgemeinen überhaupt sinnlos.
Beachten Sie, dass es keine Rolle spielt, ob das Paket standardmäßig aktiviert oder deaktiviert ist.
Einige Debhelper-Befehle werden automatisch Teile der Debian-Betreuerskripte erzeugen. Falls Sie diese automatisch erzeugten Dinge in Ihre existierenden Debian-Betreuerskripte einfügen möchten, dann müssen Sie Ihren Skripten #DEBHELPER# an der Stelle 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}"); } }
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.
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.
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.
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«.
Wenn dh(1) benutzt wird, können ihm Optionen übergeben werden, die es an jeden Debhelper-Befehl weitergibt, was im Allgemeinen besser ist, als DH_OPTIONS zu verwenden.
Dies kann nützlich sein, 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.
This is intended to be used by downstreams or specific local configurations that require a debhelper addon to be run during multiple builds without having to patch a large number of rules file. If at all possible, this should be avoided in favor of a --with flag in the rules file.
Diese Übersetzung wurde mit dem Werkzeug po4a <http://po4a.alioth.debian.org/> durch Chris Leick c.leick@vollbio.de und das deutsche Debian-Übersetzer-Team im Dezember 2011 erstellt.
Bitte melden Sie alle Fehler in der Übersetzung an debian-l10n-german@lists.debian.org oder als Fehlerbericht an das Paket debhelper.
Sie können mit dem folgenden Befehl das englische Original anzeigen man -L en Abschnitt Handbuchseite
Joey Hess <joeyh@debian.org>
2019-02-23 | 12.1.1 |