Kapitel 5. Andere Dateien im Verzeichnis debian

Inhaltsverzeichnis

5.1. README.Debian
5.2. compat
5.3. conffiles
5.4. Paket.cron.*
5.5. dirs
5.6. Paket.doc-base
5.7. docs
5.8. emacsen-*
5.9. Paket.examples
5.10. Paket.init und Paket.default
5.11. install
5.12. Paket.info
5.13. Paket.links
5.14. {Paket.|source/}lintian-overrides
5.15. manpage.*
5.15.1. manpage.1.ex
5.15.2. manpage.sgml.ex
5.15.3. manpage.xml.ex
5.16. Paket.manpages
5.17. NEWS
5.18. {post|pre}{inst|rm}
5.19. Paket.symbols
5.20. TODO
5.21. watch
5.22. source/format
5.23. source/local-options
5.24. source/local-options
5.25. patches/*

Der Befehl dh_make wurde umfangreich aktualisiert, seitdem dieses alte Dokument geschrieben wurde. Daher treffen einige Teile dieses Dokuments nicht mehr zu.

Die Überarbeitung dieser Anleitung mit aktualisierten Inhalten und weiteren praktischen Beispielen ist unter Guide for Debian Maintainers verfügbar. Bitte verwenden Sie diese neue Anleitung als primäre Anleitung.

Der Befehl debmake wird anstelle des Befehls dh_make in meinem neuen Guide for Debian Maintainers verwandt.

Um kontrollieren zu können, was genau debhelper während des Paketbauens durchführt, erstellen Sie optionale Konfigurationsdateien im Verzeichnis debian. In diesem Kapitel finden Sie einen Überblick darüber, wofür die einzelnen Dateien benötigt werden und wie ihr jeweiliges Format aussieht. Im Debian Policy Manual und in der Debian-Entwicklerreferenz finden Sie Anleitungen zum Thema Paketierung.

Der Befehl dh_make wird einige Vorlagenkonfigurationsdateien unter dem Verzeichnis debian erstellen. Schauen Sie sich alle an.

In diesem Kapitel werden zur Vereinfachung Dateien im Verzeichnis debian ohne das einleitende debian/ referenziert, wann immer die Bedeutung eindeutig ist.

Der Befehl dh_make erstellt für debhelper nicht alle Konfigurationsdateien. Falls Sie diese benötigen, müssen Sie sie mit einem Editor erstellen.

Falls Sie eine dieser Dateien verwenden möchten oder müssen, machen Sie bitte folgendes:

Alle debhelper-Konfigurationsdateien ohne ein Paket-Präfix, wie beispielsweise die Datei install, beziehen sich auf das erste Binärpaket. Wenn es mehrere Binärpakete gibt, können die jeweiligen Konfigurationen dadurch zugeordnet werden, dass der Name des Pakets als Präfix vor den Namen der Konfigurationsdatei gestellt wird. Beispiele sind Paket-1.install, Paket-2.install usw.

Alle zusätzlichen Details oder Unterschiede zwischen dem ursprünglichen Paket und Ihrer Debian-Version sollten hier dokumentiert werden.

dh_make erstellt eine Standardvorlage, die so aussieht:

gentoo for Debian
-----------------
<possible notes regarding this package - if none, delete this file>
 -- Josip Rodin <[email protected]>, Wed, 11 Nov 1998 21:02:14 +0100

Falls Sie nichts zu dokumentieren haben, löschen Sie diese Datei. Siehe dh_installdocs(1).

Die Datei compat legt die debhelper-Kompatibilitätsstufe fest. Derzeit sollten Sie debhelper V10 verwenden, indem Sie folgendes ausführen:

$ echo 10 > debian/compat

Unter bestimmten Umständen können Sie die Kompatibilitätsstufe V9 für die Kompatibilität mit älteren Systemen verwenden. Es wird aber empfohlen, unter keinen Umständen eine Stufe unterhalb von V9 zu verwenden; deren Verwendung in neuen Paketen sollte vermieden werden.

Eine der ärgerlichsten Sachen bei Software ist es, wenn Sie richtig viel Zeit und Mühe in die Konfiguration eines Programms investieren und schon das nächste Upgrade alle Ihre Änderungen zunichte macht. Debian löst dieses Problem, indem diese Konfigurationsdateien als Conffiles markiert werden. [54]. Wenn Sie ein Upgrade eines Pakets durchführen, werden Sie gefragt, ob Sie Ihre alte Konfigurationsdateien behalten wollen oder nicht.

dh_installdeb(1) markiert automatisch alle Dateien im Verzeichnis /etc als »conffiles«. Wenn Ihr Programm also nur dort Konfigurationsdateien besitzt, müssen Sie sie nicht in dieser Datei auflisten. Bei den meisten Paketarten sollte der einzige Ort, an dem sich jemals Conffiles befinden, /etc sein und daher muss diese Datei nicht existieren.

Falls Ihr Programm Konfigurationsdateien nutzt, diese aber auch selbst bearbeitet, ist es das Beste, diese nicht als Conffiles zu kennzeichnen, weil sonst dpkg den Benutzer jedes Mal auffordert, Änderungen zu bestätigen.

Falls es für das Programm, das Sie paketieren, erforderlich ist, dass jeder Benutzer die Konfigurationsdateien im Verzeichnis /etc anpassen muss, gibt es zwei populäre Arten, es so einzurichten, dass sie keine Conffiles sind, um dpkg ruhig zu stellen:

  • Erstellen Sie einen symbolischen Link im Verzeichnis /etc, der auf eine Datei im Verzeichnis /var zeigt. Dieser kann von den Betreuerskripten erzeugt werden.

  • Erstellen Sie eine Datei, die von den Betreuerskripten im Verzeichnis /etc erzeugt wird.

Für weitere Informationen über die Betreuerskripte lesen Sie Abschnitt 5.18, „{post|pre}{inst|rm}.

Falls Ihr Paket immer wiederkehrende Aufgaben erledigen muss, um korrekt zu arbeiten, können Sie diese Dateien benutzen, um das einzurichten. Sie können regelmäßige Aufgaben erstellen, die stündlich, täglich, wöchentlich oder monatlich ausgeführt werden. Alternativ kann dies auch zu jedem anderen von Ihnen gewünschten Zeitpunkt stattfinden. Die Dateinamen lauten:

  • Paket.cron.hourly - wird als /etc/cron.hourly/Paket installiert: Ausführung einmal pro Stunde.

  • Paket.cron.daily - wird als /etc/cron.daily/Paket installiert: Ausführung einmal pro Tag.

  • Paket.cron.weekly - wird als /etc/cron.weekly/Paket installiert: Ausführung einmal pro Woche.

  • Paket.cron.monthly - wird als /etc/cron.monthly/Paket installiert: Ausführung einmal pro Monat.

  • Paket.cron.d - wird als /etc/cron.d/Paket installiert: Ausführung zu anderen Zeiten.

Die meisten dieser Dateien sind Shellskripte. Die einzige Ausnahme stellt Paket.cron.d dar, das im Format einer crontab(5) vorliegen muss.

Es wird keine dedizierte cron.*-Datei für das Rotieren der Protokolldateien benötigt. Lesen Sie dazu bitte dh_installlogrotate(1) und logrotate(8).

In dieser Datei werden alle Verzeichnisse festgelegt, die wir brauchen, die aber von der normalen Installationsprozedur (»make install DESTDIR=...«, aufgerufen von »dh_auto_install«) aus irgendwelchen Gründen nicht erstellt werden. Dies bedeutet fast immer, dass es ein Problem mit dem Makefile gibt.

Für Dateien, die in der Datei install aufgelistet sind, müssen die Verzeichnisse nicht zuerst erstellt werden. Siehe Abschnitt 5.11, „install.

Am besten ist es, wenn Sie zunächst die Installation ausprobieren und diesen Mechanismus nur dann benutzen, wenn es dabei Probleme gibt. Es gibt keinen einleitenden Schrägstrich bei den Verzeichnisnamen, die in der Datei dirs aufgeführt sind.

Hat Ihr Programm außer Handbuch- und Info-Seiten noch andere Dokumentation, sollten Sie die Datei doc-base benutzen, um diese zu registrieren, damit der Benutzer sie mit Programmen wie dhelp(1), dwww(1) oder doccentral(1) finden kann.

Das schließt normalerweise HTML-, PS- und PDF-Dateien ein, die sich in /usr/share/doc/Paketname/ befinden.

So sieht die doc-base-Datei gentoo.doc-base für das Paket gentoo aus:

Document: gentoo
Title: Gentoo Manual
Author: Emil Brink
Abstract: This manual describes what Gentoo is, and how it can be used.
Section: File Management
Format: HTML
Index: /usr/share/doc/gentoo/html/index.html
Files: /usr/share/doc/gentoo/html/*.html

Informationen über das Format dieser Datei finden Sie in install-docs(8) und der Debian-Anleitung von doc-base in der lokalen Kopie /usr/share/doc/doc-base/doc-base.html/index.html, die vom Paket doc-base bereitgestellt wird.

Für weitere Details über das Installieren von zusätzlicher Dokumentation sehen Sie bitte in Abschnitt 3.3, „Installation von Dateien in ihr Zielverzeichnis“ nach.

Diese Datei enthält die Dateinamen der Dokumentationsdateien, die dh_installdocs(1) für uns in das temporäre Verzeichnis installiert.

Standardmäßig schließt das alle Dateien im obersten Verzeichnis des Quellcodes ein, die da heißen »BUGS«, »README*«, »TODO« usw.

Für gentoo werden noch weitere Dateien hinzugefügt:

BUGS
CONFIG-CHANGES
CREDITS
NEWS
README
README.gtkrc
TODO

Falls Ihr Paket Emacs-Dateien bereitstellt, die während der Installation des Pakets kompiliert werden, können Sie diese Dateien dafür nutzen.

Sie werden durch dh_installemacsen(1) ins temporäre Verzeichnis installiert.

Falls Sie dies nicht benötigen, löschen Sie die Dateien.

Der Befehl dh_installexamples(1) installiert die in dieser Datei aufgelisteten Dateien und Verzeichnisse als Beispieldateien.

Falls Ihr Paket einen Daemon enthält, der beim Hochfahren des Systems gestartet werden muss, haben Sie offensichtlich meine anfängliche Empfehlung missachtet, stimmt's? :-)

Bitte lesen Sie dh_installinit(1) dh_installsystemd(1), um ein Hochfahr-Skript bereitzustellen.

Die Datei Paket.default wird als /etc/default/Paket installiert. Diese Datei legt Voreinstellungen fest, die vom Init-Skript eingelesen werden. Diese Datei package.default wird meistens zum Setzen einiger Vorgabewerte für Schalter oder Zeitüberschreitungen verwandt. Falls in Ihrem init-Skript bestimmte einstellbare Funktionen sind, können Sie diese in der Datei package.default statt im init-Skript selbst einstellen.

Falls Ihr Programm der Originalautoren eine Datei für ein Init-Skript bereitstellt, können Sie dies entweder benutzten oder ein eigenes erstellen. Falls Sie das mitgelieferte init-Skript nicht verwenden, erstellen Sie ein neues in Paket.init. Falls das von den Originalautoren mitgelieferte Init-Skript aber gut aussieht und an der richtigen Stelle installiert wird, müssen Sie trotzdem die symbolischen Links für rc* erzeugen. Dafür müssen Sie dh_installinit in der Datei rules mit den folgenden Zeilen überschreiben:

override_dh_installinit:
        dh_installinit --onlyscripts

Falls Sie das nicht benötigen, löschen Sie die Dateien.

Falls es Dateien gibt, die in Ihr Paket installiert werden müssen, die aber vom Standardaufruf »make install« nicht erfasst werden, schreiben Sie diese Dateinamen und Ziele in die Datei install. Sie werden dann von dh_install(1) installiert. [55] Sie sollten zunächst überprüfen, ob es nicht ein spezielleres Werkzeug gibt, das verwendet werden kann. Beispielsweise sollten Dokumente in der Datei docs stehen und nicht in dieser hier.

Diese Datei install enthält pro Zeile eine zu installierende Datei, zunächst den Namen der Datei (relativ zum obersten Verzeichnis des Paketbaus), dann ein Leerzeichen und zuletzt das Installationsverzeichnis (relativ zum Install-Verzeichnis). Ein Beispiel, wo dies benutzt werden kann, ist eine Binärdatei src/bar, die nicht installiert wurde. Die Datei install könnte so aussehen:

src/bar usr/bin

Wenn dieses Paket installiert ist, bedeutet dies, dass es einen ausführbaren Befehl /usr/bin/bar geben wird.

Alternativ kann die Datei install nur den Dateinamen ohne Installationsverzeichnis enthalten, wenn sich der relative Verzeichnispfad nicht ändert. Dieses Format wird üblicherweise für große Pakete benutzt, die das Ergebnis des Baus auf mehrere Binärpakete verteilen. Dafür verwenden diese Paket-1.install, Paket-2.install usw.

Der Befehl dh_install fällt darauf zurück, im Verzeichnis debian/tmp nach Dateien zu suchen, wenn er sie im aktuellen Verzeichnis nicht findet (oder wo auch immer Sie das Programm mit --sourcedir angewiesen haben, zu suchen).

Falls Ihr Paket »info«-Seiten hat, sollten Sie diese mit dh_installinfo(1) installieren, indem Sie sie in einer Datei Paket.info auflisten.

Falls Sie zusätzliche symbolische Links in den Paketbauverzeichnissen als Paketbetreuer erstellen müssen, sollten Sie diese mit dh_link(1) installieren, indem Sie deren komplette Pfade der Quell- und Zieldateien in einer Datei Paket.links aufführen.

Falls die Debian-Richtlinien eine Ausnahme von einer Regel erlauben, erzeugt lintian eventuell eine falsche Meldung. Wenn dies der Fall ist, können Sie Paket.lintian-overrides oder source/lintian-overrides benutzen, um die Meldung zu unterdrücken. Bitte lesen Sie das Benutzerhandbuch von Lintian (https://lintian.debian.org/manual/index.html) und missbrauchen Sie diesen Mechanismus nicht.

Paket.lintian-overrides ist für das Binärpaket Paket und wird als usr/share/lintian/overrides/Paket vom Befehl dh_lintian installiert.

source/lintian-overrides ist für das Quellpaket. Diese Datei wird nicht installiert.

Ihr(e) Programm(e) sollte(n) eine Handbuchseite haben. Ist keine vorhanden, sollten Sie sie erstellen. Der Befehl dh_make erzeugt einige Vorlagendateien für Handbuchseiten. Diese müssen für jeden Befehl kopiert und bearbeitet werden, dem eine Handbuchseite fehlt. Bitte löschen Sie alle nicht benutzten Vorlagen.

Handbuchseiten werden üblicherweise in nroff(1) geschrieben. Das Beispiel manpage.1.ex ist auch in nroff geschrieben. In der Handbuchseite von man(7) finden Sie eine kurze Erklärung, wie solche Dateien bearbeitet werden können.

Der endgültige Name der Handbuchseite sollte den Namen des Programms, das dokumentiert wird, angeben. Deshalb ändern wir den Namen von »manpage« nach »gentoo«. Der Dateiname muss auch eine ».1« als erstes Suffix erhalten, was bedeutet, dass es sich um eine Handbuchseite für einen Benutzerbefehl handelt. Vergewissern Sie sich, dass dieser Abschnitt tatsächlich richtig ist. Hier ist eine kurze Liste der Abschnitte für Handbuchseiten:

Also bekommt gentoos Handbuchseite den Namen gentoo.1. Falls es in den ursprünglichen Quellen keine Handbuchseite namens gentoo.1 gibt, müssen Sie diese erstellen, indem Sie die Vorlage manpage.1.ex in gentoo.1 umbenennen und sie bearbeiten. Dabei verwenden Sie die Informationen aus dem Beispiel und die Dokumentation des Originalautors.

Sie können auch den Befehl help2man benutzen, um eine Handbuchseite aus der Ausgabe des Programms mit den Optionen »--help« und »--version« zu erzeugen. [56]

Falls Ihr Paket Handbuchseiten hat, sollten Sie sie mit dh_installman(1) installieren, indem Sie sie in einer Dateie Paket.manpages auflisten.

Um docs/gentoo.1 als Handbuchseite für das Paket gentoo zu installieren, erstellen Sie folgendermaßen eine Datei gentoo.manpages:

docs/gentoo.1

Der Befehl dh_installchangelogs(1) installiert diese Datei.

Die Dateien postinst, preinst, postrm und prerm [57] werden Betreuerskripte (engl. »maintainer scripts«) genannt. Diese Skripte werden für die Steuerung des Pakets verwendet und von dpkg aufgerufen, wenn Ihr Paket installiert, aktualisiert oder entfernt wird.

Als neuer Betreuer sollten Sie das manuelle Bearbeiten dieser Betreuerskripte vermeiden, da sie problematisch sind. Für weitere Informationen lesen Sie in dem Debian Policy Manual, Kapitel 6 »Package maintainer scripts and installation procedure« und sehen Sie sich die Beispieldateien an, die von dh_make erstellt wurden.

Falls Sie nicht auf mich gehört haben und eigene Betreuerskripte für ein Paket erstellt haben, müssen Sie sicherstellen, dass Sie sie nicht nur für den Aufruf mit install und upgrade getestet haben, sondern auch für remove und purge.

Upgrades auf die neue Version sollen ohne Rückfragen geschehen und keine Störungen oder Unterbrechungen zur Folge haben (Benutzer, die das Paket verwenden, sollen nicht bemerken, dass ein Upgrade durchgeführt wurde. Sie sollen nur feststellen, dass alte Fehler behoben wurden und das Paket eventuell neue Fähigkeiten hat).

Wenn das Upgrade nicht ohne Störung ablaufen kann (beispielsweise weil Konfigurationsdateien über verschiedene Home-Verzeichnisse verteilt sind, die einen vollkommen anderen Aufbau haben), können Sie als letzte Möglichkeit für das Paket eine sichere Voreinstellung wählen (beispielsweise den Service deaktivieren) und die von den Richtlinien verlangte ausführliche Information (README.Debian und NEWS.Debian) bereitstellen. Belästigen Sie den Benutzer nicht mit debconf-Hinweisen, die von den Betreuerskripten bei Upgrades angezeigt werden.

Das Paket ucf stellt eine ähnliche Infrastruktur wie für Dateien zur Verfügung, die als Conffile gekennzeichnet wurden. Damit bleiben von Benutzern durchgeführte Änderungen an Dateien erhalten, auch wenn diese Dateien nicht als Conffiles gekennzeichnet werden können. Beispiele hierfür sind Dateien, die von den Betreuerskripten verwaltet werden. Hierdurch sollen Probleme in der Behandlung dieser Dateien minimiert werden.

Diese Betreuerskripte gehören zu den Errungenschaften von Debian, die erklären, warum jemand Debian verwendet. Sie müssen sehr darauf achten, diese Skripte nicht zu einem Grund für Ärger werden zu lassen.

Die Paketierung einer Bibliothek ist für einen neuen Betreuer nicht leicht und sollte vermieden werden. Hat Ihr Paket allerdings Bibliotheken, dann sollten Sie eine Datei debian/Paket.symbols haben. Lesen Sie Abschnitt A.2, „debian/Paket.symbols verwalten“.

Der Befehl dh_installdocs(1) installiert diese Datei.

Das Format der Datei watch ist in der Handbuchseite von uscan(1) dokumentiert. Die Datei watch konfiguriert das Programm uscan (aus dem Paket devscripts), um die Site zu überwachen, von der Sie die Originalquellen bezogen haben. Dies wird außerdem von dem Dienst Debian Package Tracker benutzt.

Hier sind seine Inhalte:

# watch control file for uscan
version=3
http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate

Normalerweise würde mit einer watch-Datei die URL unter »http://sf.net/gentoo« heruntergeladen und nach Links im Format »<a href=...>« durchsucht. Der Basisname (nur der Teil nach dem letzten »/«) jeder verlinkten URL wird mit dem regulären Perl-Ausdruck (siehe perlre(1)) »gentoo-(.+)\.tar\.gz« verglichen. Von allen Dateien, auf die der Ausdruck passt, wird die Datei mit der höchsten Versionsnummer heruntergeladen. Das Programm uupdate wird dann ausgeführt, um daraus den aktualisierten Quelltextbaum zu erzeugen.

Dies stimmt zwar für andere Websites, doch das Herunterladen von SourceForge unter http://sf.net ist eine Ausnahme. Wenn die Datei watch eine URL enthält, auf die der reguläre Perl-Ausdruck »^http://sf\.net/« passt, wird diese vom Programm uscan durch »http://qa.debian.org/watch/sf.php/« ersetzt und erst dann die nachfolgenden Regeln angewendet. Die URL-Umleitungsfunktion unter http://qa.debian.org/ ist entwickelt worden, um einen stabilen Umleitungsservice für jedes watch-Muster der Form »http://sf.net/Projekt/tar-Name-(.+)\.tar\.gz« in der Datei watch bereitzustellen. Hierdurch wird das Problem gelöst, dass SourceForge-URLs regelmäßig geändert werden.

Falls die Originalautoren eine kryptographische Signatur des Tarballs bereitstellen, wird empfohlen, seine Authentizität mittels der Option pgpsigurlmangle zu prüfen, wie dies in uscan(1) beschrieben ist.

In der Datei debian/source/format soll eine einzelne Zeile stehen, in der das gewünschte Format für das Quellpaket angegeben wird (lesen Sie dpkg-source(1) für eine ausführliche Liste). Nach Squeeze sollte dort entweder:

  • 3.0 (native) für native Debian-Pakete oder

  • 3.0 (quilt) für alles andere stehen.

Das neuere Quellformat 3.0 (quilt) zeichnet Änderungen in einer Patchserie im Verzeichnis debian/patches für quilt auf. Diese Änderungen werden dann während des Entpackens des Quellpakets automatisch angewendet. [58] Die Debian-spezifischen Änderungen werden einfach in einem Archiv namens debian.tar.gz gespeichert, das alle Dateien im Verzeichnis debian enthält. Mit diesem neuen Format können binäre Dateien wie PNG-Icons vom Paketbetreuer eingebunden werden, ohne Tricks anwenden zu müssen. [59]

Wenn dpkg-source ein Quellpaket im Quellformat 3.0 (quilt) entpackt, werden automatisch alle Patches angewendet, die in debian/patches/series aufgeführt sind. Sie können das Anwenden der Patches nach dem Entpacken verhindern, indem Sie die Option --skip-patches benutzen.

Wenn Sie die Paketierungsarbeiten für Debian in einem Versionskontrollsystem verwalten wollen, erstellen Sie üblicherweise einen Zweig (z. B. upstream), in dem Sie die Quellen des Originalautors verfolgen und einen weiteren Zweig (z. B. üblicherweise master für Git), in dem Sie das Debian-Paket verfolgen. Für letzteres wollen Sie sicherlich die unveränderten Ursprungsquellen zusammen mit Ihren debian/*-Dateien für das Paketieren haben, um das Zusammenführen von neuen Ursprungsquellen zu vereinfachen.

Nachdem Sie ein Paket gebaut haben, bleiben die Patches im Quelltext normalerweise erhalten. Sie müssen sie manuell entfernen, indem Sie »dquilt pop -a« aufrufen, bevor Sie in den master-Zweig einchecken können. Sie können dies automatisieren, indem Sie die optionale Datei debian/source/local-options hinzufügen und dort »unapply-patches« hineinschreiben. Diese Datei wird nicht in das erzeugte Quellpaket aufgenommen und verändert nur das lokale Bauverhalten. Diese Datei kann auch »abort-on-upstream-changes« enthalten (siehe dpkg-source(1)).

unapply-patches
abort-on-upstream-changes

Die automatisch erstellten Dateien im Quellbaum können für das Paketieren recht störend wirken, da sie unbedeutende große Patch-Dateien hervorrufen. Es gibt angepasste Module wie dh_autoreconf, um dieses Problem zu vereinfachen. Dies wird in Abschnitt 4.4.3, „Anpassungen der Datei rules beschrieben.

Sie können dem Optionsargument --extend-diff-ignore von dpkg-source(1) einen regulären Perl-Ausdruck übergeben, um Änderungen, die an den automatisch erstellten Dateien beim Erstellen des Quellpakets vorgenommen wurden, zu ignorieren.

Als allgemeine Lösung, um dieses Problem der automatisch erstellten Dateien zu adressieren, können Sie so ein Optionsargument an dpkg-source in der Datei source/options des Quellpakets speichern. Folgendes wird die Erstellung von Patch-Dateien für config.sub, config.guess und Makefile überspringen:

extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"

Das alte Quellformat 1.0 erzeugte eine einzelne große diff.gz-Datei, in der sowohl die Paketbetreuungsdateien unter debian als auch Patches für den Quelltext enthalten waren. So ein Paket ist etwas schwierig zu untersuchen und zu verstehen, wenn später der Quelltext geändert werden soll. Das ist nicht so schön.

Das neuere Quellformat 3.0 (quilt) speichert Patches in debian/patches/*-Dateien unter Verwendung des Befehls quilt ab. Diese Patches sowie andere Paketdaten bleiben alle innerhalb des Verzeichnisses debian und werden als debian.tar.gz-Datei gepackt. Da der Befehl dpkg-source in 3.0 (quilt)-Quellen die Patch-Daten im quilt-Format verarbeiten kann, ohne auf das Paket quilt zurückzugreifen, wird keine Build-Depends für quilt benötigt. [60]

Der Befehl quilt wird in der Handbuchseite von quilt(1) erklärt. Er zeichnet Änderungen an den Quellen als Stapel von -p1-Patch-Dateien im Verzeichnis debian/patches auf, dadurch bleibt der Quelltextbaum außerhalb des debian-Verzeichnisses unangetastet. Die Reihenfolge der Patches wird in der Datei debian/patches/series gespeichert. Sie können die Patches leicht anwenden (=push), entfernen (=pop) und aktualisieren. [61]

Für den Abschnitt Kapitel 3, Den Quellcode verändern haben wir drei Patches in debian/patches erstellt.

Da die Debian-Patches in debian/patches enthalten sind, stellen Sie bitte sicher, dass der Befehl dquilt korrekt eingerichtet ist, so wie in Abschnitt 3.1, „Einrichten von quilt beschrieben.

Wenn später jemand (Sie selbst eingeschlossen) einen Patch namens foo.patch für die Quellen erstellt, ist die Veränderung eines 3.0 (quilt)-Quellpakets recht einfach:

$ dpkg-source -x gentoo_0.9.12.dsc
$ cd gentoo-0.9.12
$ dquilt import ../foo.patch
$ dquilt push
$ dquilt refresh
$ dquilt header -e
... Patch beschreiben

Die Patches, die in dem neuen Quellformat 3.0 (quilt) gespeichert werden, müssen frei von Ungenauigkeiten (fuzz) sein. Sie können dies mit »dquilt pop -a; while dquilt push; do dquilt refresh; done« sicherstellen.



[55] Dies ersetzt den veralteten Befehl dh_movefiles(1), der durch die Datei files konfiguriert wurde.

[56] Beachten Sie, dass die Platzhalter-Handbuchseite von help2man behaupten wird, dass detailliertere Informationen im info-System vorhanden seien. Falls dem Befehl eine Info-Seite fehlt, sollten Sie die von help2man erstellte Handbuchseite manuell bearbeiten.

[57] Trotz der hier verwendeten Abkürzungssyntax {pre,post}{inst,rm} von bash, um die Dateinamen zu bezeichnen, sollten Sie reine POSIX-Syntax für diese Betreuerskripte verwenden, um kompatibel zu der Verwendung von dash als System-Shell zu bleiben.

[58] Siehe DebSrc3.0 für eine Zusammenfassung zum Wechsel auf die neuen Quellformate 3.0 (quilt) und 3.0 (native).

[59] Tatsächlich unterstützt dieses neue Format sogar mehrere ursprüngliche Tarbälle und mehr Kompressionsmethoden. Dies würde in diesem Dokument aber zu weit führen.

[60] Es wurden verschiedene Methoden für die Organisation der Patches in Debian-Paketen vorgeschlagen und auch angewendet. Das quilt-System ist das bevorzugteste Organisationssystem. Weitere Systeme sind u.A. dpatch, dbs und cdbs. Viele von diesen Systemen speichern solche Patches in debian/patches/*-Dateien ab.

[61] Falls Sie einen Sponsor darum bitten, Ihr Paket hochzuladen, ist diese Art der klaren Aufteilung und Dokumentation Ihrer Änderungen sehr wichtig, um die Durchsicht Ihres Pakets durch den Sponsor zu beschleunigen.