Kapitel 5. Andere Dateien im Verzeichnis `debian`

# Kapitel 5. Andere Dateien im Verzeichnis `debian`

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:

- Benennen Sie die Konfigurationsdateien um, so dass sie den tatsächlichen Paketnamen anstatt ``Paket`` verwenden.

- Passen Sie die Inhalte der Vorlagedateien Ihren Bedürfnissen an.

- Löschen Sie Vorlagedateien, die Sie nicht benötigen.

- Passen Sie die Datei `control` an, falls notwendig (siehe Abschnitt 4.1, „`control`“).

- Passen Sie die Datei `rules` an, falls notwendig (siehe Abschnitt 4.4, „`rules`“).

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.

## 5.1. `README.Debian`

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

## 5.2. `compat`

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.

## 5.3. `conffiles`

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

## 5.4. ``Paket`.cron.*`

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

## 5.5. `dirs`

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.

## 5.6. ``Paket`.doc-base`

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.

## 5.7. `docs`

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

## 5.8. `emacsen-*`

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.

## 5.9. ``Paket`.examples`

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

## 5.10. ``Paket`.init` und ``Paket`.default`

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.

## 5.11. `install`

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

## 5.12. ``Paket`.info`

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

## 5.13. ``Paket`.links`

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.

## 5.14. `{`Paket`.|source/}lintian-overrides`

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.

## 5.15. `manpage.*`

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.

### 5.15.1. `manpage.1.ex`

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:

Abschnitt | Beschreibung | Hinweise
--- | --- | ---
1 | Dienstprogramme für Benutzer | Ausführbare Befehle oder Skripte
2 | Systemaufrufe | Vom Kernel bereitgestellte Funktionen
3 | Bibliotheksfunktionen | Funktionen innerhalb Systembibliotheken
4 | Besondere Dateien | Normalerweise innerhalb von `/dev`
5 | Dateiformate | Z.B. Format von `/etc/passwd`
6 | Spiele | Spiele oder andere belanglose Programme
7 | Makropakete | Wie man-Makros
8 | Systemadministration | Programme, die typischerweise nur von Root ausgeführt werden
9 | Kernelroutinen | Nicht standardisierte Aufrufe und Interna

Also bekommt `gentoo`s 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]

### 5.15.2. `manpage.sgml.ex`

Falls Sie es andererseits bevorzugen, in SGML anstatt nroff zu schreiben, können Sie die Vorlage `manpage.sgml.ex` benutzen. Dann müssen Sie Folgendes tun:

- Benennen Sie die Datei um, beispielsweise in `gentoo.sgml`.

- Installieren Sie das Paket `docbook-to-man`

- Fügen Sie `docbook-to-man` der Zeile `Build-Depends` in der Datei `control` hinzu.

- Fügen Sie das Target `override_dh_auto_build` in Ihrer Datei `rules` hinzu:

      override_dh_auto_build:
              docbook-to-man debian/gentoo.sgml > debian/gentoo.1
              dh_auto_build

### 5.15.3. `manpage.xml.ex`

Falls Sie XML gegenüber SGML bevorzugen, können Sie die Vorlage `manpage.xml.ex` benutzen. Dann müssen Sie Folgendes tun:

- Umbenennen der Quelldatei in etwas wie `gentoo.1.xml`

- Installieren Sie das Paket `docbook-xsl` und einen XSLT-Prozessor wie `xsltproc` (empfohlen).

- Fügen Sie `docbook-xsl`, `docbook-xml` und `xsltproc` der Zeile `Build-Depends` in der Datei `control` hinzu

- Fügen Sie das Target `override_dh_auto_build` in Ihrer Datei `rules` hinzu:

      override_dh_auto_build:
              xsltproc --nonet \
               --param make.year.ranges 1 \
               --param make.single.year.ranges 1 \
               --param man.charmap.use.subset 0 \
               -o debian/ \
      http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\
              debian/gentoo.1.xml
              dh_auto_build

## 5.16. ``Paket`.manpages`

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

## 5.17. `NEWS`

Der Befehl dh_installchangelogs(1) installiert diese Datei.

## 5.18. `{post|pre}{inst|rm}`

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.

## 5.19. ``Paket`.symbols`

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

## 5.20. `TODO`

Der Befehl dh_installdocs(1) installiert diese Datei.

## 5.21. `watch`

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.

## 5.22. `source/format`

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.

## 5.23. `source/local-options`

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

## 5.24. `source/local-options`

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)$"

## 5.25. `patches/*`

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.

[54] Lesen Sie dpkg(1) und das Debian Policy Manual, »D.2.5 Conffiles«.

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

Kapitel 4. Benötigte Dateien im Verzeichnis `debian` |  | Kapitel 6. Bau des Pakets