Einer für alle

Deb-Source 3.0 macht Schluss mit Patch-Wildwuchs und hat das Patchsystem Quilt bereits integriert. Für Paketbauer heißt das vor allem, dass sie weniger Klimmzüge machen müssen, um Patches mit Quilt zu nutzen (Abbildung 2). Kam in einem Paket bisher ein anderes Patchsystem als Quilt zum Einsatz und ist der Umstieg geplant, bedeutet dies, alles aus den Dateien im Debian-Ordner zu entfernen, was mit dem alten Patchsystem zu tun hat.

Abbildung 2: Wenn ein Programm es regelmäßig mit Patches zu tun bekommt, macht das neue Sourceformat das Leben des Betreuers bedeutend einfacher.

Dazu gehören besonders der Eintrag im Feld »Build-Depends« in »debian/control« sowie die Regeln in »debian/rules« , die die Patch- und Unpatch-Funktionen des Patchsystems aufrufen. Letzteres gilt auch für alle, die Quilt zuvor bereits als separates Patchsystem nutzten. Die Patches in »debian/patches« können bleiben, es sind aber eventuell vorhandene Header aus ihnen zu entfernen – insbesondere Dpatch sah solche Patch-Header vor. Die Patches sollten den Level 1 verwenden, also mittels »patch -p1« händisch anwendbar sein.

Die Vorgehensweise: Nutzer erstellen eine Datei namens »debian/patches/series« und legen für jedes Patch in »debian/patches« eine Zeile an, die die Syntax »+ Patchname« hat. Heißt das Patch »test.diff« , lautet die passende Zeile »+ test.diff« . Damit ist Quilt einsatzbereit. Beim nächsten Bauvorgang wendet es alle Patches in »debian/patches/series« an, und beim Aufruf des »clean« -Target in »debian/rules« macht es die Änderungen der Patches rückgängig.

Übrigens: »Dpkg-Source« ist nicht tolerant, wenn es darum geht, dass Patches korrekt sind. Lässt sich ein Patch nur mit Fuzz anwenden, verweigert »Dpkg-Source« die Arbeit. Entsprechende Patches sind also neu zu erstellen. Tipp: Weil das Verändern von Dateien außerhalb des Debian-Ordners nicht mehr möglich ist, legt das neue »dpkg-source« von erkannten Änderungen zu Beginn des Bauprozesses ein eigenes Quilt-Patch an. Wer die Ursprungsquellen angefasst hat, tut gut daran, für diese Änderungen Patches händisch und aufgesplittet zu erstellen – im Nachhinein ist es sonst schwierig, Veränderungen zu verstehen.

Blick in die Werkzeugkiste

Die maßgeblichen Umbauarbeiten für den Umstieg auf Deb-Src 3.0 mit Quilt sind damit beendet. Wie sieht es mit den anderen Werkzeugen aus dem Package-Universum aus? Für die Pakete, die ohnehin überwiegend mit Binärdateien hantieren, ändert sich nichts. Verschiedene Systeme zur Pflege eines eigenen Debian-FTP-Repository – darunter auch Reprepro – werten für ihre Arbeit die ».dsc-Files« aus, die beim Deb-Src 3.0 logischerweise die Dateinamen der neuen Sourcedateien enthalten. Auch hier sind beim Umstieg keine Probleme zu erwarten.

Abbildung 3: Ansteigende Beliebtheit: Eine Grafik von Enrico Zini zeigt, wie viele Entwickler ihre Debian-Pakete schon auf das neue Sourceformat umgebaut haben.

Etwas hakeliger sind die Helferlein, die Git, SVN oder Bazaar und das Paketbauen verbinden: Git funktioniert zwar einwandfrei und ist wie immer der Musterschüler, aber bei »svn-buildpackage« fehlt noch die Unterstützung für mehrere Quelltext-Tarbälle. Bazaar hat bis zum 3.0-Format noch einen längeren Weg vor sich, aber in Colin Watson findet sich ein prominenter Debian-Developer, der das System verwendet und die Weiterentwicklung von »bzr-builddeb« in nächster Zeit vorantreiben will.

Lintian [5], das unbedingt zu verwenden ist, um die (Source-)Pakete auf ihre Konformität mit der Debian-Policy zu überprüfen, funktioniert größtenteils. Allerdings klappt das Testen von mehreren Tarballs im Quelltext nicht. Lintian überprüft jeweils nur den ersten Tarball im ».dsc« -File und ignoriert alle weiteren. Im schlimmsten Fall würde es also Fehler in Zusatz-Tarballs übersehen.