Debian-Fans feierten im August Geburtstag (Abbildung 1). Seit 17 Jahren schwören sie auf ihr freies Betriebssystem, weil es weniger zicke als andere Systeme. Neben der konservativen Release-Politik gibt es einen weiteren Grund dafür, dass Debian-Systeme als “rockstable” gelten: die Debian-Policy oder genauer das “Debian Policy Manual” [1].

Abbildung 1: Auf der Geburtstagswebseite Thank.debian.net bedanken sich derzeit fast 3000 Leute. Debians Beliebtheit resultiert unter anderem aus dem stabilisierenden Projekt-Gesetzbuch, der Debian-Policy.
Dieses Projekt-Gesetzbuch kodifiziert das Technische. Allen Architektur- oder Konventionsänderungen geht eine Änderung der Policy voraus. Die Entwickler müssen ihre Pakete hinsichtlich Konformität mit der Policy prüfen, bevor sie sie in das Archiv hochladen. Ein Versäumnis gilt als verpönt: Lädt ein Maintainer sein Paket erneut hoch, nachdem er ohne Test Fehler übersah, wird es peinlich für ihn.
Der Weg des Gesetzes
Kapitel eins beginnt harmlos. Es erläutert das Wesen der Policy sowie ihre Entstehungsgeschichte und erklärt im Stile eines RFC Begriffe wie Ascii oder UTF-8. Das zweite Kapitel beschreibt die Struktur des Debian-Archivs. Dafür zitiert die Policy die Debian Free Software Guidelines und definiert die drei Archivbereiche “main”, “contrib” und “non-free” – Admins kennen diese Begriffe aus »/etc/apt/sources.list«. Unterkategorien, Sections genannt, gibt es für alle Entwicklerzweige. Die Policy listet sie nicht einzeln auf, sie sind aber zum Beispiel für Unstable auf [2] zu finden.
Ans Eingemachte
Ausschließlich um Pakete geht es in den folgenden fünf Kapiteln. Sie bilden das technische Rückgrat einer Debian-Installation und legen zum Beispiel die Zielordner für Bibliotheken fest. Dabei implementiert die Policy vorhandene Standards. Es ist wie bei der Umsetzung von EU-Verordnungen: Vorgaben aus Brüssel treten in den Mitgliedsstaaten nicht unmittelbar in Kraft, sondern jeder Staat implementiert sie mit der eigenen Legislative im nationalen Recht.
Ebenso schafft die Debian-Policy auf der Grundlage allgemeiner Standards wie etwa der Linux Standard Base (LSB, [3]) oder des Filesystem Hierarchy Standard (FHS, [4]) projektweit Verbindlichkeit. Debian-Entwickler müssen daher nicht alle diese Spezifikationen studieren. Sie sind auf der sicheren Seite, wenn sie sich an die Policy halten. Ein weiterer Vorteil ist, dass das Projekt mit Änderungen in LSB oder FHS koordiniert gleichzieht.
Unter Kontrolle
Debian teilt alle Pakete in die Kategorien “Source” und “Binary” ein, so lernt es der Paketbauer. Unter Sourcepaketen sind die unkompilierten Quellen zu verstehen, zusammen mit allen Patches, die daraus die fertigen Binaries machen. Letztere sind die Deb-Pakete. Nach der Policy, im vierten Kapitel behandelt, müssen sie etwa über einen eindeutige Namen und Beschreibungen verfügen. Spannender finden viele jedoch die Sourcepakete. Für deren Zustand sorgen ab Kapitel vier präzise Vorgaben.
Wichtig war den Verfassern zunächst die Syntax von Dateien im Unterverzeichnis »debian«. In einem jungfräulichen Quelltext-Ordner angelegt, “debianisiert” dieses Verzeichnis eine Software. Insbesondere fallen das Changelog und das Copyright ins Gewicht sowie die Rules: Das ist das Makefile, mit dessen Hilfe am Ende das Programm »dpkg-buildpackage« fertige ».deb«-Dateien produziert.
Das ganze fünfte Kapitel widmet sich der kritischen Control-Datei. Sie enthält die Informationen zum Sourcepaket und dem daraus generierten Binary. Dazu gehört zum Beispiel die eingangs erwähnte Section, in der das Programm später landen soll. Die Kontrolldatei ist übrigens auf mehreren Stufen der Paketbau-Treppe anzutreffen. So liegt sie etwa im Debian-Ordner des Programmquelltextes, wo der Maintainer sie editiert. Sie ist aber auch im fertigen Binärpaket enthalten.
Wer also ein beliebiges Paket mit der Endung ».deb« mit
ar x Dateiname
entpackt und anschließend
tar xvfz control.tar.gz
ausführt, hat die Debian-Kontrolldatei vor sich. Ein Blick hinein zeigt Schlüsselwörter, die am Anfang nicht eingerückter Zeilen stehen. Sie heißen Felder und sind mit einem Doppelpunkt vom Rest der Zeile getrennt. Sie klären etwa über den Betreuer, über Veränderer oder Abhängigkeiten auf. Kapitel fünf, Teil sechs der Policy erklärt alle Felder. Anschließend erlaubt sie es den Entwicklern, Felder selbst zu definieren, solange diese ihnen das Präfix »XBS-« voranstellen.
Weisungsgebunden
Mit den Maintainer-Skripten beschäftigt sich das ganze Kapitel sechs. So heißen Shellskripte, die vor oder nach der Installation beziehungsweise dem Entfernen eines Pakets in Aktion treten. Die Skripte mit den einigermaßen sprechenden Namen »preinst«, »postinst« sowie »prerm« und »postrm« müssen mit einer in der Policy kanonisierten Liste von Argumenten zurechtkommen.
Vorschriften macht das Policy-Manual auch über das engere Paketbaugeschäft hinaus. So erhalten Debianer Anweisungen, wie sie Benutzer per Paketinstallation anlegen und löschen oder wie Debians Initsystem funktioniert. Nachdem Kapitel zehn weite Teile des FHS implementiert, setzt sich der Paketbauer in Kapitel elf mit Ausnahmen im Hinblick auf besondere Programmtypen auseinander. So gelten für Tools auf X11-Basis andere Bedingungen als für Daemons. Am Ende harrt die Dokumentation: Kapitel zwölf behandelt unter anderem Manpages.
Kommissar Lintian
Glücklicherweise verfügen Debian-Entwickler über das Helferlein »lintian« [5], das Debian-Pakete auf Policy-Konformität überprüft. Gerade wegen dieses Assistenten sind Fehler peinlich für den Entwickler. Der Aufpasser Lintian erhält die Macht aus der Hand des Paketbetreuers: In der Kontrolldatei gibt dieser die verwendete Policy-Version bekannt.
Lintian weiß Bescheid: Bei Policy-Updates erfährt es stets ein Makeover. Sein erster Test ist, ob die eingetragene Policy-Version aktuell ist. Ist sie veraltet, geht die Motzerei los (Abbildung 2). Dann nimmt Lintian alle Source- und Binärdateien unter die Lupe. Es unterscheidet zwischen Warnings und Errors. Ein Paket mit Lintian-Errors hat Archiv-Verbot.

Abbildung 2: Bevor das gebaute Drbd8-Paket ins Archiv darf, hat der Betreuer noch einiges zu erledigen: Das Perl-Skript Lintian als Meckerfritze in Aktion.
Made by Debian
Die Maintainer und andere diskutieren auf der Debian-Policy-Mailingliste [6] gewohnt temperamentvoll, haben bisher aber immer eine Lösung gefunden. Umfassende Updates geschehen ohnehin selten: Zwischen den Versionen 3.8.0.0 und 3.9.0.0 lagen mehr als zwei Jahre. Auch das Update von Version 3.7.0.0 auf 3.8.0.0 dauerte so lange. (ake)
| Infos |
|---|
| [1] Debian Policy Manual: [http://www.debian.org/doc/debian-policy/]
[2] Paket-Sektionen in Unstable:[http://packages.debian.org/unstable/] [3] Linux Standard Base:[http://www.linuxfoundation.org/collaborate/workgroups/lsb] [4] Filesystem Hierarchy Standard:[http://www.pathname.com/fhs/] [5] Lintian: [http://lintian.debian.org] [6] Debian-Policy-Mailingliste:[http://lists.debian.org/debian-policy/] |
| Der Autor |
|---|
| Martin Gerhard Loschwitz ist Senior Technical Consultant bei Linbit und seit vielen Jahren Debian-GNU/Linux-Entwickler. |






