© Helder Almeida, 123RF.com

Debian 6.0 enthält neben vielen angenehmen Features für Endnutzer auch eine wichtige Neuerung für Entwickler: das Source-Paketformat 3.0. Admins profitieren vom 3.0-Format durch neue Funktionen, die Bau und Pflege ihrer Pakete vereinfachen.

Die Veröffentlichung von Debian GNU/Linux 6.0 (Squeeze) ist für Admins von Debian-Systemen ein freudiges Ereignis. Denn Squeeze bringt neben Verbesserungen für den laufenden Betrieb auch essenzielle Neuerungen für all jene mit, die von der eigenen Software Debian-Pakete erstellen oder als Debian-Entwickler fertige Software für Debian vorbereiten: Dpkg in Squeeze beherrscht das Source-Paketformat 3.0 und bietet damit eine ganze Latte an Funktionen und Gimmicks, die das Verpacken von Software bequem machen. Der folgenden Artikel berichtet, welche Vorteile das neue Paketformat bringt.

Was noch immer gilt

Die Änderungen an Dpkg in Squeeze betreffen nur das Format der Sourcen eines Debian-Pakets. An den Binärpaketen ändert sich wenig: Noch immer handelt es sich bei ».deb« -Dateien um Ar-Archive der Version 2, die mit »ar x« ihren Inhalt preisgeben. Sie bestehen wie gewohnt aus den TGZ-Archiven »binary.tar.gz« und »control.tar.gz« und einer Textdatei namens »debian-binary« .

Zwar sind im Lauf der Jahre ein paar optionale Felder im »control« -File eines Pakets dazugekommen, wer nachschauen möchte, findet sie in »control.tar.gz« . Diese Optionen betreffen die meisten Entwickler aber nicht.

Maßgeblich sind die Veränderungen an den Dateien, aus denen später fertige ».deb« entstehen. Wer sich schon mit dem Debian-Paketing befasst hat, weiß: Die Quellen eines Pakets umfassen die originalen Quellen eines Programms. Sie liegen in Form eines TGZ-Archivs mit der Endung ».orig.tar.gz« vor. Dazu gehört eine Datei, die auf ».diff.gz« endet – sie enthält dann alle Veränderungen, die der Paketbauer am originalen Quelltext während des Paketierungsvorgangs vorgenommen hat.

Zu den beiden Dateien gesellt sich eine dritte mit der Endung ».dsc« , die den Namen des Quellpakets sowie Informationen wie etwa die MD5- und SHA-Checksummen und zusätzlich die Größe der beiden zuvor erwähnten Dateien enthält. Sie ist vom Paketbauer zu signieren und landet bei offiziellen Paketen mit den zwei anderen Dateien auf dem Debian-FTP-Server.

Eine geht, eine kommt

So war es bisher, und an dieser Stelle treffen Paketbauer auf die erste handfeste Neuerung im 3.0-Format: Statt der ».diff.gz-Datei« gibt es nun eine ».debian.tar.gz« -Datei, die die Debian-eigenen Veränderungen enthält. Der Grund für die Änderung: Die ».diff.gz« -Dateien waren normale Patches, die »dpkg-buildpackage« auf den entpackten Original-Quelltext mittels »patch« anwendeten.

Diese Prozedur stößt bei Binärdateien jedoch schnell an ihre Grenzen: Patches sind Textdateien, in denen sich Binaries nur über Umwege wie »uuencode« und »uudecode« unterbringen lassen. PNG-Icons sind ein gutes Beispiel: Ein im Debian-Unterverzeichnis existierendes PNG-Bild hat »dpkg-buildpackage« bisher einfach ignoriert. Der Maintainer musste es deshalb erst in Base64 enkodieren und später beim Paketbau per »rules« -Anweisung wieder zurückwandeln.

Im Sourceformat 3.0 ist dieser Umweg nicht mehr nötig: Die ».debian.tar.gz« -Datei entpackt der Ersteller des Pakets in das »debian« -Unterverzeichnis. Alle Dateien, die im TGZ-Archiv liegen, landen im Quelltext und sind von dort aus weiter verwendbar.

Mehrere Upstream-Tarballs

Eine weitere Neuerung im Sourceformat 3.0 erlaubt es, mehrere Tarballs für Originalsourcen zu verwenden. Bisher gab es lediglich das eine schon erwähnte ».orig.tar.gz« -File, künftig können die Paketbauer noch zusätzliche verwenden. Die neue Funktion ist besonders in jenen Fällen praktisch, wenn der Programmierer des zu paketierenden Werkzeugs ein Hauptprogramm und viele Zusatzmodule herausgibt.

In dem neuen Format Deb-Src 3.0 lassen sich all diese Komponenten in einem Paket verteilen, ohne die Upstream-Tarballs erneuern zu müssen. Dazu benennt der Paketbauer ein TGZ-Archiv nach dem folgenden Schema: »paketname_version.orig-Komponente.tar.gz« . Der unter »Komponente« angegebene Wert ist wichtig, denn er bestimmt, in welchem Ordner dieser Tarball später im entpackten Quelltext landet.

Steht hier der Wert »test« , müssen sich die Dateien dieses Tarball im Quelltext später auch in dem Ordner »test« befinden. Beim ersten Bauen wird also zunächst händisch der Ordner »test« angelegt und dann mittels »tar -C test -xvzf ../(Paketname_Version).orig-test.tar.gz« der Inhalt des TGZ-Archivs in diesen Ordner hinein entpackt.

Beim nächsten Anlauf zu einem Paketbau mit »dpkg-buildpackage« erkennt das Programm die Zusatzquellen und integriert dann den zweiten Tarball in die ».dsc« -Datei. Weitere Informationen zu diesem Vorgehen liefert eine ausführliche Anleitung von Raphael Hertzog, der als Mastermind hinter dem 3.0-Sourceformat 3.0 [1] steht.

Neue Kompressionsformate

Quelltext-Tarballs konnten bisher ausschließlich das Gzip-Format verwenden, sollte »dpkg-source« damit umgehen können. Das ist im neuen Format für Sourcepakete anders: In 3.0 ist auch Bzip2 unterstützt. Als Dreingabe steht sogar LZMA zur Verfügung, ist aber mit Vorsicht zu genießen: Besteht der Plan, das Paket irgendwann in das offizielle Debian-Archiv hochzuladen, dann ist LZMA keine Option, zumindest fehlt im Augenblick dafür der Support auf Debians Haupt-FTP-Server.

Sowohl Bzip2- als auch LZMA-Tarballs sind genauso zu verwenden wie bisher Gzip-Tarballs, es ist aber – auch wenn es trivial klingt – darauf zu achten, dass die Dateien nicht auf ».orig.tar.gz« enden, sondern auf ».orig.tar.bz2« oder auf ».orig.tar.lzma« .

Keine blinden Passagiere

Die Urheber von Software meinen es häufig gut mit ihren Benutzern und packen in ihren Programmquelltext ein »debian« -Verzeichnis, mit dem Endanwender dann schnell und leicht zu einem ».deb« -Paket kommen. Für Debian-Entwickler war das ärgerlich: Mit dem zuvor schon beschriebenen Diff-Verfahrens war es nicht sinnvoll möglich, Files im Debian-Ordner zu entfernen, »dpkg-source« hat fehlende Dateien beim Erstellen des ».diff« -File einfach ignoriert. Das Resultat war, dass selbst nach dem Erstellen des Pakets durch einen Debian-Entwickler im »debian« -Verzeichnis oft noch Altlasten des gleichen Ordners vom Programmautor vorhanden waren.

Deb-Source 3.0 löst das Problem: Erkennt »dpkg-source« im Tarball der originalen Quellen ein Debian-Verzeichnis, löscht es den Ordner, und zwar bevor es die Debian-Änderungen auf den Quelltext anwendet. Wer Pakete gebaut hat, in denen er sich auf vorhandene Files in »debian« verlässt, muss beim Umstieg auf Deb-Source 3 Anpassungen vornehmen.

Problemfall Patches

Die Vorgehensweise, damit »dpkg-source« die Bestimmungen von Deb-Source 3 für ein Paket einsetzt, ist einfach: Es genügt, »3.0 (quilt)« in das File »debian/source/format« zu schreiben, fertig. Zumindest in der Theorie, denn wer im Paket Patches verwendet, muss Umbauarbeiten auf sich nehmen.

Für das Sourceformat 3.0 sind zwei Namen im Umlauf, auf der einen Seite “3.0 (native)” und auf der anderen “3.0 (quilt)”. Letzteres hat das Patchsystem Quilt implementiert, eine wichtige Neuerung in Source 3.0 (Abbildung 1).

Abbildung 1: Das Paket »bzr[UCC:x00-fake-italic]« nutzt das 3.0-(quilt)-Format, hier zu erkennen am ».debian.tar.gz«-File.

Unter Debian-Entwicklern ist es verpönt, Veränderungen außerhalb des Debian-Ordners einfach in das ».diff« -File zu übernehmen. Die herrschende Auffassung lautetet, dass das ».diff.gz« -File nur und ausschließlich Veränderungen in »debian/« vornehmen darf. Wer diesem ungeschriebenen Gesetz folgte, stand aber vor einem Problem: Wie ist mit unvermeidbaren Änderungen im Quelltext umzugehen? Viele Autoren verwenden zum Beispiel für ihre Software hartkodierte Pfade. Wenn diese nicht dem Filesystem Hierarchy Standard (FHS) entsprechen, muss ein Debian-Entwickler die Pfade ändern, wenn er nicht gegen die Debian-Policy [2] verstoßen will. Abhilfe schafft nur eine Lösung, bei der im Debian-Ordner Patches liegen, die während des Bauvorgangs quasi on the Fly auf den Quelltext angewendet werden.

Allerdings wäre es mühsam, für jedes einzelne Paket die Logik, die ein solches System braucht, separat zu implementieren. So kursierten bereits fertige Lösungen: Dpatch [3] war eine davon, »dbs« hatte ebenso eine eigene Patchlogik, aber die bekannteste Lösung der letzten Jahre heißt Quilt [4]. All diese Systeme beruhen auf dem Prinzip, dass im »debian/patches« -Ordner Diff-Dateien liegen, die beim Bauen des Pakets dynamisch angewendet und beim Aufrufen des »clean« -Target in »debian/rules« wieder entfernt werden. Für jedes einzelne System waren dabei in »debian/rules« andere Einstellungen zu treffen.

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.

Fazit

Für den Bau von Debian-Paketen sei der Einsatz des neuen Sourceformats wärmstens empfohlen. Es erleichtert und erspart viele Schritte, besonders die Patchverwaltung profitiert davon. Die Entwickler akzeptieren (Abbildung 3) das neue System bereits.