Kapitel 5. Andere Dateien im Verzeichnis debian

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:

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

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.

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

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.

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

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

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.

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.

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