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. menu
5.18. NEWS
5.19. {post|pre}{inst|rm}
5.20. Paket.symbols
5.21. TODO
5.22. watch
5.23. source/format
5.24. source/local-options
5.25. source/local-options
5.26. patches/*

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. Bitte lesen Sie das Debian Policy Manual und die Debian-Entwicklerreferenz für einen Leitfaden zum Paketieren.

Der Befehl dh_make erstellt einige Vorlagen für Konfigurationsdateien im Verzeichnis debian. Die meisten sind mit dem Suffix ».ex« versehen. Andere haben den Namen des Binärpakets als Präfix wie beispielsweise Paket. Schauen Sie sich alle an. [54]

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 <joy-mg@debian.org>, 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 V9 verwenden, indem Sie folgendes ausführen:

$ echo 9 > debian/compat

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. [55]. Wenn Sie ein Upgrade eines Pakets durchführen werden, 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.19, „{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. Dafür lesen Sie 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? :-)

Die Datei Paket.init wird als Skript /etc/init.d/Paket installiert, das den Daemon startet und beendet. Die Vorlage mit einem sehr allgemeinen Grundgerüst wird als init.d.ex vom Befehl dh_make bereitgestellt. Sie müssen sie umbenennen und wahrscheinlich (viel) anpassen. Gleichzeitig müssen Sie darauf achten, dass die Kopfzeilen konform zur Linux Standard Base (LSB) sind. Es wird von dh_installinit(1) in das temporäre Verzeichnis installiert.

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 zur Deaktivierung der Ausführung eines Daemons oder zur Einstellung einiger voreingestellter 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. [56] 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 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 (/usr/share/doc/lintian/lintian.html/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. [57]

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 eine Datei gentoo.manpages folgendermaßen:

docs/gentoo.1

Benutzer des X-Window-Systems haben normalerweise einen Fenstermanager mit einem Menü, das konfiguriert werden kann, um Programme zu starten. Falls sie das Debian-Paket menu installiert haben, werden Menüeinträge für die installierten Programme automatisch hinzugefügt.

Hier ist die Standarddatei menu.ex, die von dh_make erstellt wurde:

?package(gentoo):needs=X11|text|vc|wm \
        section=Applications/see-menu-manual\
        title=gentoo command=/usr/bin/gentoo

Das erste Feld nach dem Doppelpunkt ist needs und bestimmt, welche Art der Benutzerschnittstelle das Programm braucht. Ändern Sie dies auf eine der aufgeführten Alternativen, beispielsweise text oder X11.

Das nächste ist der Abschnitt (section), in dem der Menü- und Untermenüeintrag später erscheinen soll. [58]

Das Feld title enthält den Namen des Programms. Dieser kann mit Großbuchstaben beginnen, sollte aber kurz gehalten werden.

Zuletzt das Feld command, das den Befehlsaufruf zum Starten des Programms enthält.

Lassen Sie uns den Dateinamen in menu und den Menüeintrag wie folgt ändern:

?package(gentoo): needs=X11 \
        section=Applications/Tools \
        title=Gentoo command=gentoo

Sie können noch weitere Felder wie longtitle, icon, hints usw. hinzufügen. Siehe dh_installmenu(1), menufile(5), update-menus(1) und The Debian Menu sub-policy für weitere Informationen.

Der Befehl dh_installchangelogs(1) installiert diese Datei.

Die Dateien postinst, preinst, postrm und prerm [59] 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 zu einem Grund für Ärger werden zu lassen.

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 Seite zu überwachen, von der Sie die Originalquellen bezogen haben. Dies wird außerdem von dem Dienst Debian External Health Status (DEHS) 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. [60] 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. [61]

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. [62]

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. [63]

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.



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

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

[57] 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.

[58] Die derzeitige Liste der Abschnitte befindet sich in The Debian Menu sub-policy, Kapitel 2.1 »Preferred menu structure«. Für squeeze gab es eine große Reorganisation der Menüstruktur.

[59] 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.

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

[61] 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.

[62] 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.

[63] 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.