debhelper-compat-upgrade-checklist - Upgrade-Prüfliste
für unterstützte Debhelper-Kompatiblitätsstufen
ÜBERSICHT
Dieses Dokument ist eine Upgrade-Prüfliste für alle
unterstützten Debhelper-Kompatibilitätsstufen. Es listet
darüber hinaus alle unterstützten
Debhelper-Kompatibilitätsstufen auf.
Informationen darüber, wie die Kompatibilitätsstufen
deklariert werden, ist in "KOMPATIBILITÄTSSTUFEN" in
debhelper(7) zu finden.
Falls Sie ein Upgrade von einer (jetzt) überholten
Kompatibilitätsstufe durchführen, schlagen Sie bitte in
debhelper-obsolete-compat(7) nach.
Folgende Kompatibilitätsstufen sind verfügbar:
- v15
- Diese Kompatibilitätsstufe ist immer noch für die
Entwicklung offen. Verwenden Sie sie mit Vorsicht.
Änderungen gegenüber v14 sind:
- Die Erweiterung single-binary für dh wird nicht mehr
implizit von Quellpaketen aktiviert, die einen einzelnen Eintrag
Package in debian/control haben. Falls das Paket
diefür Abkürzungen für Einzel-Binärpakete
benötigt, muss es die Erweiterung single-binary explizit
aktivieren.
Das kann mit einem Build-Depends auf
dh-sequence-single-binary erreicht werden.
Jedes --without single-binary, das an dh
übergeben wurde, um die Warnung im Kompatibilitätsmodus 14
zu vermeiden, kann jetzt entfernt werden, um debian/rules zu
vereinfachen, ohne die Warnung auszulösen.
- Jetzt ist es in den meisten Fällen ein Fehler, paketlose Versionen
von Debhelper Konfigurationsdateien zu verwenden, wenn zwei oder mehr
Binärpakete in debian/control aufgeführt sind.
Veraltete Dateien sollten (von debian/foo) in
debian/Paket.foo umbenannt werden, wobei Paket das erste der
in debian/control aufgeführten Binärpakete ist.
Die Hauptausnahme bei dieser Änderung sind Dateien wie
debian/changelog, debian/NEWS und debian/copyright,
wo die gleiche Datei per Voreinstellung für alle Pakete verwendet
wird. Diese Fälle bleiben unverändert.
- Es ist jetzt ein Fehler, eine Paket-Datei ohne den Paket-Prefix für
--name zu verwenden, selbst wenn das Quellpaket nur ein
Binärpaket erzeugt. Falls Sie beispielsweise einen
debian/bar.service mit dem folgenden Schnipsel in
debian/rules hatten:
override_dh_installsystemd:
dh_installsystemd -p foo --name bar
Dann müssen Sie debian/bar.service in
debian/foo.bar.service umbenennen.
- v14
- Diese Kompatibilitätsstufe ist immer noch für die
Entwicklung offen. Verwenden Sie sie mit Vorsicht.
Änderungen gegenüber v13 sind:
- Die Reihenfolge und Platzierung für dh_strip_nondeterminism,
dh_compress, und dh_fixperm hat sich geändert.
Früher wurden diese drei Befehle in der aufgeführten
Reihenfolge zwischen dh_installxfonts und dh_missing
ausgeführt.
Ihre neue Platzierung ist nach dh_missing (arch:all)
oder dh_shlibdeps (arch:any) und vor dh_installdeb.
Außerdem ist ihre neue Reihenfolge dh_fixperms,
dh_strip_nondeterminism und dann dh_compress.
Diese Änderung macht möglicherweise
Aktualisierungen von Erweiterungen von Drittanbietern notwendig, die
einen dieser drei Befehle als Anker oder Hook-Ziele für einen
dieser Befehle verwenden, und die Annahmen über die Reihenfolge
der Befehle treffen.
Außerdem können sich
dh_strip_nondeterminism und dh_compress sowie alle
Erweiterungen von Drittanbietern, die diese Anker verwenden, nicht mehr
auf die »Mode/Ownership«-Normalisierung durch
dh_fixperms verlassen, was zur Offenlegung von Fehlern in der Art
von falschen Modi oder Besitzrechten in dem resultierenden
Binärpaket führen kann.
Bitte melden Sie den Entwicklern der entsprechenden Werkzeugen
jeden dieser Fehler. Sie können die Betreuer von debhelper
in Kopie setzen.
- Das Werkzeug dh_installsysusers ist jetzt in der Standardsequenz
enthalten. Es verarbeitet systemd-Sysuser-Dateien.
- Das Werkzeug dh_installsystemduser aktiviert jetzt in der
Voreinstellung Systemd-User-Units, startet sie bei der Installation,
startet sie bei Upgrades neu und stoppt sie bei der Deinstallation eines
Pakets.
- Die Verwendung des dh_gconf-Befehls in Override- und Hook-Zielen
führt jetzt zu einem Fehler. Der dh_gconf-Befehl war seit
Jahren ein Leerbefehl und ist in Debhelper 13.4 entfernt worden.
- Das Werkzeug dh_installalternatives wird jetzt in der
Standard-dh-Sequenz nach dh_link und nicht mehr nach
dh_installinitramfs ausgeführt.
- Dieser Punkt ist nur auf Quellpakete anwendbar, die genau einen
Abschnitt Paket in debian/control haben.
Der Befehl dh_auto_install verwendet jetzt
standardmäßig und bedingungslos
--destdir=debian/tmp. Der Spezialfall für Quellpakete, die
ein einziges Binärpaket bauen, ist jetzt in die Erweiterung
single-binary von dh verschoben worden. Bitte beachten
Sie, dass diese Erweiterung im Kompatibilitätsmodus 14, aber
nicht im Kompatibilitätsmodus 15 standardmäßig
aktiviert ist (siehe den nächsten Punkt).
- Dieser Punkt ist nur auf Quellpakete anwendbar, die genau einen
Abschnitt Paket in debian/control haben.
Der dh-Sequenzer wird eine Warnung ausgeben, wenn die
single-binary-Erweiterung implizit aktiviert wurde, um Betreuer
vor der anstehenden Änderung in Kompatibilitätsstufe 15 in
dh_auto_install zu warnen. Die implizite Aktivierung ist eine
Funktionalität für den Übergang, um das Risiko zu
reduzieren, das diese Änderung mit sich bringt. In
Kompatibilitätsstufe 15 wird die implizite Aktivierung nicht mehr
auslösen.
Betreuern wird dringend geraten, die
single-binary-Erweiterung entweder explizit zu aktivieren, um das
bisherige Verhalten beizubehalten (bspw. durch Hinzufügen von
dh-sequence-single-binary zu Build-Depends), oder
dh_auto_install explizit mit --destdir aufzurufen, wenn
verwendet, und dann --without single-binary bei dh
anzugeben (Letzteres zum Abstellen der Warnung).
Der Zweck dieser Änderung besteht darin,
»Überraschungen« beim späteren
Hinzufügen eines zweiten Binärpakets zu vermeiden. In der
Vergangenheit hat Debhelper kommentarlos sein Verhalten geändert,
was dazu führte, dass versehentlich leere Pakete ins Archiv
hochgeladen wurden. Bei der neuen Vorgehensweise wird die
single-binary-Erweiterung diese Diskrepanz feststellen und den
Betreuer vor dem, was passieren wird, warnen.
- -
- Das Werkzeug dh_gencontrol wendet nun automatisch
Ersetzungsvariable mit Beziehungen auf die relevanten Felder an. Das
bedeutet, dass viele Ersetzungsvariable wie ${misc:Depends} und
${shlibs:Depends} nicht mehr explizit in debian/control
aufgeführt werden müssen. Das betrifft jede
Ersetzungsvariable, die nach einem Feld benannt wird, das die installierte
Version von dpkg als eine Beziehung oder ein
abhängigkeitsähnliches Feld versteht. Zur Zeit der
Erstellung des Dokuments besteht diese Liste aus:
- Pre-Depends
- Depends
- Recommends
- Suggests
- Enhances
- Conflicts
- Breaks
- Replaces
- Provides
- Built-Using
- Static-Built-Using
Das bedeutet, dass zum Beispiel Depends: foo,
${misc:Depends} in debian/control zu Depends: foo
verkürzt werden kann. Außerdem kann als Beispiel für
diese Funktionalität Depends: ${misc:Depends},
${shlibs:Depends} komplett entfernt werden.
Beachten Sie, dass andere Ersetzungsvariable wie
B${binary:Version} von dieser Änderung nicht betroffen sind und
weiterhin wenn notwendig explizit verwendet werden sollen. Bei Paketen, bei
denen Essential: yes gesetzt ist und bei denen manuell das Feld
${shlibs:Depends} in das Feld Pre-Depends übertragen
wurde, wird dh_shlibdeps dies ebenfalls automatisch handhaben (siehe
den nächsten Punkt zu Kompatibilitätsstufen).
Siehe
<https://lists.debian.org/debian-devel/2024/02/msg00230.html>
für Details zu diesem Vorschlag. Die Zusammenfassung in
<https://lists.debian.org/debian-devel/2024/03/msg00030.html>
behandelt auch die Fälle, bei denen Ersetzungsvariable eine Anpassung
benötigen. Der allgemeinste Fall beinhaltet die Verwendung der Option
-d von dpkg-shlibdeps, möglicherweise durch
dh_shlibdeps.
Hinweis: Diese Änderung wird Falsch-positiv-Bewertungen von
einem nicht korrigiertem lintian(1) verursachen. Bitte prüfen
Sie anhand von <https://bugs.debian.org/1067653>, ob lintian(1)
diese Änderung unterstützt.
- Das Werkzeug dh_shlibdeps verwendet in der Voreinstellung
${shlibs:Pre-Depends} für Pakete mit Essential: yes.
Beachten Sie, dass durch die obige Änderung von
dh_gencontrol jedes Paket, das dh_gencontrol verwendet,
nicht von dieser Migration betroffen ist.
- Wenn dh_auto_install ausgeführt wird, stellen die von
debhelper bereitgestellten Bausysteme sicher, dass alle Pfade in
destdir minimale Benutzerberechtigungen haben (chmod -R
u+rwX), um seltsame Berechtigung verweigert-Fehler
während des Bauens zu vermeiden.
Drittanbietern von Debhelper-Bausystemen wird empfohlen, dies
gleichfalls zu unterstützen. Das kann mittels der
Ausführung von
$this->ensure_minimal_permissions($destdir) if not compat(13);
im debhelper Bausystem-Code aus deren sub
install Implementierung erreicht werden, und zwar nach der
Ausführung des Codes der Originalautoren.
Falls Sie dh_auto_install nicht verwenden, und Sie
seltsame Berechtigung verweigert-Fehler erhalten, können
Sie das oft durch die Ausführung von chmod -R u+rxW
VERZEICHNIS beheben, nachdem Sie das Installationsziel des
Bausystems der Originalautoren ausgeführt haben.
Bitte überprüfen Sie, ob Ihr Paket irgendwelche
Spezialfälle aufweist, in denen Berechtigungen von Dateien oder
Verzeichnissen das »Benutzer-Schreibbit« nicht gesetzt
haben dürfen. Bekannte Fälle sind *.ali-Dateien
sowie /etc/sudoers.d, die dh_fixperms
standardmäßig berichtigt.
Das Problem mit ungewöhnlichen Berechtigungen war in
der Theorie schon immer vorhanden. Dadurch, dass dh_fixperms seit
Kompatibilitätsstufe 14 in der Abfolge später aufgerufen
wird, und mit der Änderung, fakeroot
standardmäßig zu entfernen (was einige dieser Probleme
verdeckte), ist es aber deutlich sichtbarer geworden. Diese
Änderung soll diese Problematik eingrenzen.
- Die Debhelper-Konfigurationsdateien unterliegen den folgenden
Änderungen:
- Es veranlasst nun in den meisten Fällen eine Warnung, die
paketlosen Versionen von Debhelper-Konfigurationsdateien zu verwenden,
wenn zwei oder mehr Binärpakete in debian/control
aufgeführt sind. Veraltete Dateien sollten (von debian/foo)
in debian/Paket.foo umbenannt werden, wobei Paket das erste
der in debian/control aufgeführten Binärpakete ist.
Die Hauptausnahme bei dieser Änderung sind Dateien wie
debian/changelog, debian/NEWS und debian/copyright,
wo die gleiche Datei per Voreinstellung für alle Pakete verwendet
wird. Diese Fälle bleiben unverändert. Das Werkzeug
Debhelper wird bei Verwendung dieser Dateien eine Warnung
auslösen.
In Kompatibilitätsstufe 15 (oder neuer) ist das
geändert zu einem Fehler.
- Jetzt wird eine Warnung ausgelöst, wenn eine Paket-Datei ohne den
Paket-Präfix für --name verwendet wird, selbst wenn
das Quellpaket nur ein Binärpaket erzeugt. Falls Sie beispielsweise
einen debian/bar.service mit dem folgenden Schnipsel in
debian/rules hatten:
override_dh_installsystemd:
dh_installsystemd -p foo --name bar
Dann müssen Sie debian/bar.service in
debian/foo.bar.service umbenennen.
In Kompatibilitätsstufe 15 (oder neuer) ist das
geändert zu einem Fehler.
- Die standardmäßigen Nachschlageregeln für auf
Dh_Lib basierende Werkzeuge nehmen jetzt an, dass
Konfigurationsdateien nicht mehr benannt werden (--name) noch
standardmäßig Architektureinschränkungen
unterstützen. Falls Sie mit einem zu Debhelper ähnlichem
Werkzeug eines Drittanbieters arbeiten und Unterstützung für
eine dieser Funktionalitäten benötigen, dann erstellen Sie
bitte bei dem Werkzeug einen Fehlerbericht und bitten, seine
Konfigurationsdatei mit den relevanten Optionen in seinem Aufruf
pkgfile bekanntzugeben.
Beachten Sie, dass debhelper seine Regeln für
die Mehrzahl seiner Werkzeuge basierend auf der Nutzungsanalyse
über codesearch.debian.org ebenfalls selbst anpasst.
Sollten Sie sich auf eine Funktionalität verlassen, wie
beispielsweise Architektureinschränkungen für eine
gegebene Konfigurationsdatei, die nicht mehr unterstützt wird, so
stellen Sie bitte ein Funktionalitätswunsch für diesen
Anwendungsfall und sie wird möglicherweise wieder
hergestellt.
- -
- Pakete, die das Bausystem cmake verwenden, sollten die folgenden
Änderungen beachten:
- Das Bausystem cmake gibt jetzt
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON an cmake(1) weiter, womit
einige Reproduzierbarkeitsprobleme vermieden werden.
- Das Bausystem cmake setzt nun die Umgebungsvariable ASMFLAGS
falls sie nicht gesetzt ist und ASFLAGS vorhanden ist. Der erstere
Name (ASMFLAGS) ist der Name, den cmake erwartet,
während der letztere (ASFLAGS) der Name ist, den
dpkg-buildpackage(1) verwendet.
- Das Bausystem cmake verwendet im dh_auto_install(1)-Aufruf
jetzt cmake --install anstelle von ninja install. Jede
Außerkraftsetzung von dh_auto_install, die Extra-Parameter
an das Bausystem der Originalautoren weiterreicht, sollte
überprüft werden.
- -
- Pakete, die das Bausystem meson verwenden, sollten die folgenden
Änderungen beachten:
- Das Bausystem meson übergibt nun
--auto-features=enabled an meson.
- Das Bausystem meson+ninja verwendet im
dh_auto_install(1)-Aufruf jetzt meson install anstelle von
ninja install. Jede Außerkraftsetzung von
dh_auto_install, die Extra-Parameter an das Bausystem der
Originalautoren weiterreicht, sollte überprüft werden.
- Die Datei debian/compat wird nicht mehr als Quelle zur
Spezifikation der Debhelper-Kompatibilitätsstufe akzeptiert. Setzen
Sie die Kompatibilitätsstufe in dem Feld X-DH-Compat des
Source-Abschnitts von debian/control.
Beachten Sie, dass diese Änderung das erste Mal in
Kraft gesetzt wird, wenn Kompatibilitätsstufe 14 als stabil
deklariert wird. Damit wird vermieden, Pakete zu beschädigen, die
schon zu Kompatibilitätsstufe 14 migriert wurden, während
diese Änderung noch experimentell war.
- Das Werkzeug dh_installtmpfiles führt nun --remove
beim Entfernen und --purge beim vollständigen Löschen
von Paketen aus. Für Letzteres ist Systemd v256 erforderlich.
- Das Werkzeug dh_lintian akzeptiert nicht mehr länger
architekturabhängige Dateien zur Außerkraftsetzungen
für Pakete mit Multi-Arch: same in debian/control,
weil diese dann nicht mehr koinstallierbar wären. Fälle, die
von diesem Fehler betroffen sind, sollten zu architekturabhängigen
Außerkraftsetzungen von lintian(1) wechseln.
- v13
- Dies ist der empfohlene Betriebsmodus.
Die Änderungen gegenüber v12 sind:
- Das Bausystem meson+ninja benutzt anstelle von ninja test
nun meson 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
widersprüchliche Definitionen einer Handbuchseite entdeckt. Dies
kommt üblicherweise vor, wenn 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.
Wie damit umgegangen wird, können Sie der Beschreibung für
die Umgebungsvariablen in "ENVIRONMENT" in debhelper(1)
entnehmen.
Dieses Funktionalität hat sich zwischen Debhelper 13
und Debhelper 13.2 geändert.
- Der Befehl dh wird nun einen Fehler ausgeben, falls ein Override-
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 lässt sich zu einer nicht-fatalen Warnung
zurückändern, 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
Override-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.
Beachten Sie, dass dh_installtmpfiles auf
debian/Paket.tmpfiles reagiert, wo dh_installsystemd einen
Nahmen ohne das nachfolgende »s« benutzt hat.
- Viele dh_*-Werkzeuge unterstützen nun eine
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 ist Teil der
Funktionen filearray und filedoublearray.
- Der Befehlssequenzer dh wird jetzt alle Hooks und Override-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 die betroffene Logik aus diesen Zielen
heraus verschieben. Z. B. müsste nicht-testbezogener
Paketierungscode von override_dh_auto_test nach
execute_after_dh_auto_build oder
execute_before_dh_auto_install verschoben werden.
- Das Bausystem cmake übergibt nun
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON an cmake(1), um den
automatischen Installationsprozess zu beschleunigen. Falls Sie aus
irgendeinem Grund beim alten Verhalten bleiben möchten,
übersteuern Sie den Schalter:
dh_auto_configure -- -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=OFF ...
- v12
- Änderungen gegenüber v11 sind:
- Das Werkzeug dh_makeshlibs erzeugt nun standardmäßig
Shlibs-Dateien mit versionierter Abhängigkeit. Das bedeutet, dass
-VUpstream-Version (alias -V) nun die Voreinstellung ist.
Falls eine nicht versionierte Abhängigkeit in der
Shlibs-Datei gewünscht wird, kann dies stattdessen durch
Übergabe von -VNone erreicht werden. Siehe aber auch
dh_makeshlibs(1) für die Vorbehalte gegen nicht
versionierte Abhängigkeiten.
- 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- und ähnlichen Funktionen
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 die Konfiguration
für das Init-System Upstart nicht mehr. Stattdessen bricht es das
Bauen ab, wenn es eine alte Upstart-Konfigurationsdatei findet. Der Fehler
soll den Paketbetreuer daran erinnern, sicherzugehen, dass die mit
vorherigen Versionen des Pakets mitgelieferten Konfigdateien (falls
vorhanden) sauber entfernt werden.
- Das Werkzeug dh_installdeb wird die Grundprüfung einiger
dpkg-maintscript-helper(1)-Befehle durchführen und sich mit
einer Fehlermeldung beenden, falls die Befehle ungültig zu sein
scheinen.
- Das Werkzeug dh_missing wird nun auf --list-missing
voreingestellt.
- Das Werkzeug dh_makeshlibs wird jetzt 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 und sie werden mit einem Fehler scheitern. Falls
Sie diese Befehle überspringen wollen, fügen Sie bitte ein
leeres Override-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 auf die
Voreinstellung des Bausystems – diese sollte /usr/libexec
sein (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, etwa wie im
folgenden Beispiel:
override_dh_auto_configure:
dh_auto_configure -- --libexecdir=/usr/libexec
Beachten Sie das -- vor dem Parameter
--libexecdir.
- Rückwirkend in debhelper/13.5 entfernt:
Das dh_installdeb-Werkzeug sollte eigentlich nicht
länger die vom Betreuer bereitgestellte conffiles-Datei
installieren, weil das als unnötig erachtet wurde. Das
remove-on-upgrade aus Dpkg Version 1.20 machte die Datei jedoch
wieder relevant und dh_installdeb installiert sie jetzt wieder in
den Kompatiblitätsstufen 12 und höher.
- Das Werkzeug dh_installsystemd beruht nicht mehr auf
dh_installinit, um Systemd-Dienste zu handhaben, die über
eine SysVinit-Alternative verfügen. In einem solchen Fall
müssen jetzt beide Werkzeuge benutzt werden, um sicherzustellen,
dass der Dienst sowohl unter SysVinit als auch unter Systemd sauber
gestartet wird.
Falls Sie eine Methode haben, dh_installinit
außer Kraft zu setzen (z. B. indem Sie es mit --no-start
aufrufen), dann werden Sie jetzt wahrscheinlich auch eine für
dh_installsystemd benötigen.
Diese Änderung lässt dh_installinit ein
misc:Pre-Depends für init-system-helpers (>=
1.54~) einspeisen. Bitte stellen Sie sicher, dass das Paket
${misc:Pre-Depends} in seinem Feld Pre-Depends
aufführt, bevor Sie ein Upgrade auf Kompatibilitätsstufe
12 durchführen.
- Das Drittherstellerwerkzeug dh_golang (aus dem Paket
dh-golang) akzeptiert jetzt standardmäßig die
Variable DH_GOLANG_EXCLUDES für die Quelleninstallation in
-dev-Paketen und das 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 ist jetzt entfernt worden. Bitte
verwenden Sie stattdessen das Drittanbieterbausystem pybuild.
- v11
- Von diesem Modus wird abgeraten.
Von der Kompatibilitätsstufe 11 wird für neue
Pakete abgeraten, da sie von Funktionalitätswechselwirkungen
zwischen dh_installinit und dh_installsystemd betroffen ist, die dazu
führen, dass in manchen Fällen Dienste nicht korrekt
laufen. Bitte erwägen Sie, stattdessen die
Kompatibilitätsstufen 10 oder 12 zu benutzen. Weitere
Einzelheiten über das Thema sind in Debian#887904 und
<https://lists.debian.org/debian-release/2019/04/msg01442.html>
verfügbar.
Änderungen gegenüber v10 sind:
- 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 Override-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 Bausystem makefile ü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 Bausystem autoconf übergibt nun
--runstatedir=/run an ./configure.
- Das Bausystem cmake ü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 jetzt 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 Programmfehler in Befehlen
offenlegen, die nicht in Debhelper enthalten sind.
- Die Hilfsprogramme dh_installdocs, dh_installexamples,
dh_installinfo und dh_installman beenden sich jetzt mit
Fehlermeldung, 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, bei dem die obigen Werkzeuge stillschweigend
fehlschlagende Suchen mit Mustern erlauben, welche zur Angabe von
Dokumentation verwendet werden.
- Die Hilfsprogramme dh_installdocs, dh_installexamples,
dh_installinfo und dh_installman akzeptieren nun den
Parameter --sourcedir mit derselben Bedeutung wie
dh_install. Überdies fallen sie jetzt, so wie
dh_install, auf debian/tmp zurück.
Migrationshinweis: Ein Fehler in Debhelper 11 bis 11.1.5
führte fälschlicherweise dazu, dass dh_installinfo
--sourcedir ignoriert hat.
- Die Bausysteme perl-makemaker und perl-build
übergeben -I. nicht mehr an Perl. Pakete, die dieses
Verhalten benötigen, können meistens die Umgebungsvariable
PERL5LIB als Ersatz verwenden, z. B. durch Eintragen von export
PERL5LIB=. in ihre »debian/rules«-Datei (oder
dergleichen).
- PERL_USE_UNSAFE_INC wird jetzt von dh oder den
dh_auto_*-Werkzeugen nicht mehr gesetzt. Sie diente als
Übergangslösung, um zu verhindern, dass das gleichzeitige
Bauen vieler Pakete scheitert.
Beachten Sie, dass sie irgendwann komplett überholt
wird, da die Ursprungsautoren beabsichtigen, die Unterstützung
für die Umgebungsvariable PERL_USE_UNSAFE_INC
einzustellen. Wenn es so weit ist, wird diese Variable
nachträglich auch aus bestehenden Kompatibilitätsstufen
entfernt.
- Das Hilfsprogramm dh_makeshlibs wird nun mit einer Fehlermeldung
beendet, falls Objdump nach der Auswertung einer gegebenen Datei einen
Rückgabewert ungleich null zurückliefert.
- Die Werkzeuge dh_installdocs und dh_installexamples
können jetzt die meiste Dokumentation in einem anderen Pfad
installieren, 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 ist und Sie zur nächsten
Änderung springen können, falls ein angegebenes Quellpaket
nur ein einziges Binärpaket in debian/control
enthält oder keine -doc-Pakete dabei sind.
Standardmäßig werden diese Werkzeuge nun
versuchen, ein »Hauptpaket für die Dokumentation«
(ab hier Hauptdokumentationspaket genannt) für jedes
-doc-Paket zu bestimmen. Falls sie ein derartiges
Hauptdokumentationspaket finden, werden sie nun die Dokumentation
in den Pfad /usr/share/doc/Hauptdokumentationspaket im
angegebenen Dokumentationspaket installieren. Das heißt, der Pfad
kann sich ändern, aber die Dokumentation wird immer noch im
-doc-Paket mitgeliefert.
Die Option --doc-main-package kann benutzt werden, wenn
die automatische Erkennung unzureichend ist oder um den Pfad auf seinen
vorherigen Wert zurückzusetzen, falls es einen Grund gibt, von
der Empfehlung der Debian-Richtlinien 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 suchen 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.
- v10
- Änderungen gegenüber v9 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 Pferdefuß hier liegt darin, dass dh_* nun nur noch
nachverfolgt, was in einem einzelnen Override-Ziel geschieht. Wenn alle
Aufrufe eines angegebenen dh_cmd-Befehls im selben Override-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 Override-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. das Setzen von Dateinamen in
Anführungszeichen).
- Voreinstellung für den Befehl dh_installinit ist nun
--restart-after-upgrade. Für Pakete, die das vorhergehende
Verhalten erfordern, verwenden Sie bitte
--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
erwünscht ist.
- Die systemd-Sequenz ist nun standardmäßig aktiviert.
Bitte übergeben Sie --without systemd an dh, falls
dies für ein angegebenes Paket nicht erwünscht ist.
- 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 in den fünf Jahren ihres Bestehens keine Berichte zu Problemen
gab, die von diesem Fehler verursacht wurden, wurde sie nicht
überarbeitet, sondern entfernt.
- v9
- Änderungen gegenüber v8 sind:
Dieser Modus ist missbilligt.
- v8
- Änderungen gegenüber v7 sind:
- Befehle werden fehlschlagen anstatt zu warnen, wenn ihnen unbekannte
Optionen übergeben werden.
- dh_makeshlibs führt dpkg-gensymbols auf allen
gemeinsamen Bibliotheken aus, für die es Shlib-Dateien generiert,
wobei Bibliotheken mit -X ausgeschlossen werden können.
Außerdem werden dpkg-gensymbols Bibliotheken an
unüblichen Orten übergeben, ohne dass es diese vorher
verarbeitet haben wird, was dazu führen kann, dass sich einige
Pakete nicht bauen lassen.
- dh erfordert, dass die auszuführende Sequenz als erster
Parameter angegeben wird und sämtliche Schalter danach kommen. Das
heißt, Sie schreiben nicht »dh --foo $@«,
sondern »dh $@ --foo«.
- dh_auto_* bevorzugt Perls Module::Build
gegenüber Makefile.PL.
Dieser Modus ist missbilligt.
- v7
- Dieser Modus ist missbilligt.
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).
- debhelper-obsolete-compat(7)
- Führen Sie ein Upgrade von einer (jetzt) obsoleten
Kompatibilitätsstufe aus? Dieses Dokument enthält die
Upgrade-Prüflisten bis zur ältesten unterstützten
Stufe.
- debhelper(7)
- Generelle Informationen über das Debhelper-Rahmenwerk. Dieses
Dokument beschreibt auch, wie Sie die von Ihnen gewählte
Debhelper-Kompatibilitätsstufe deklarieren.
Ü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
Niels Thykier <niels@thykier.net>
Joey Hess