Es ist grundsätzlich eine gute Idee, jeglichen Programmcode immer und ausschließlich über .deb-Packages ins System zu bringen. Nur in sehr einfachen Fällen ist es zu empfehlen, den Code auf anderem Wege zu installieren (wobei meine Empfehlung hier auf die Verwendung von GNU Stow lauten muss).

Debian-Packages können im Augenblick in ihrer Source-Form zwei verschiedene Formen annehmen. Veränderungen an dieser Aussage sind in Arbeit, da man das Source-Format flexibilisieren möchte.

Eine Debian native Package besteht aus einem .tar.gz und einem .dsc-File und kommt dann zum Einsatz, wenn ein Programm nur für Debian gebaut wurde und außerhalb des Debian-Projektes nicht erhältlich ist.

Man erkennt aus Debian native Packages gebaute Binary-Packages üblicherweise an der Versionsnummer, die keinen Bindestrich enthält (z.B. debianutils_2.5.5).

Eine normale Package besteht aus einem .orig.tar.gz, einem .diff.gz und einem .dsc. Dabei legt Debian großen Wert darauf, dass - soweit möglich - das .orig.tar.gz der lediglich umbenannte Upstream-Tarball ist, man also per md5-Summe prüfen kann, ob man hier auch die richtige Software baut. Das ist allerdings nicht in allen Fällen möglich¹⁾. Das .diff.gz ist ein Patch gegen den Upstream-Tarball, der die für die Debian-Package notwendigen Änderungen enthält.

Man erkennt “normale” Packages üblicherweise an der Versionsnummer, die einen Bindestrich enthält (z.B. exim4_4.24-1). Im Beispiel ist exim4 der Name der Source-Package, 4.24 die Upstream-Version und 1 die Debian-Revision, also die n-te Version der Debian-Package für die genannte Version des Upstreams.

Das .dsc-File, das die Source Package beschreibt, enthält die md5-Prüfsumme der anderen Bestandteile der Source Package und ist im Fall “offizieller” Debian-Packages vom zuständigen Maintainer GPG-signiert.

Einige Binary-Packages sind ebenfalls vom Maintainer signiert. Das ist allerdings zum heutigen Zeitpunkt noch nicht zwingend, und die Tools prüfen diese Signaturen auch nicht.

Das Source-Format soll sich in den nächsten Monaten verändern. So möchte man neben gzip auch bzip2 als Kompressionsmethode zulassen und auch erlauben, dass es mehrere Patch-Files geben kann. Rückwärtskompatibilität soll aber so gewährleistet sein, dass die Packages von heute auch noch mit den Tools von morgen gebaut werden können.

Aus einer Source-Package entsteht im Build-Prozess eine oder mehrere Binary-Packages. Von der Architektur abhängige Packages enthalten den Architekturstring (z.B. i386, powerpc etc) im Dateinamen; von der Architektur unabhängige Packages tragen den Architekturstring all.

Eine Source-Package lässt sich mit dem Kommando dpkg-source -x [dscfile] in ein subdirectory des aktuellen Verzeichnisses auspacken. dpkg-source -x packt zuerst den Upstream-Tarball aus, wendet dann den .diff an und spielt noch etwas mit den Zugriffsrechten, die sich im .diff nicht vernünftig umsetzen lassen.

Ergebnis ist ein Verzeichnis, dessen Inhalt grob dem modifizierten Upstream entspricht, dem zusätzlich ein Verzeichnis “debian” hinzugefügt wird, das die Dateien enthält, die den Bau der Package steuern.

Der Bau einer Binary-Package läuft in den folgenden Schritten ab:

• Konfiguration (configure)
• Compile/Bau (make)
• Installation (make install)
• Einpacken der Ergebnisse zum fertigen .deb

Die Erstellung der Binary-Package wird durch die Datei debian/rules - fast immer ein Makefile - gesteuert und läuft so ab, dass keine root-Rechte notwendig sind. Die Installation der fertigen Package findet in ein Subdirectory von debian/ statt, so dass das gastgebende System durch den Packagebau selbst nicht beeinflusst wird. Einzelne Schritte des Packagebaus benötigen mindestens “gefälschte” root-Rechte, um Dateirechte korrekt setzen zu können. Hierfür stellt Debian das Programm fakeroot zur Verfügung.

Diese Schritte können automatisch gesteuert durch das Programm dpkg-buildpackage oder besser durch das komfortablere debuild. Außer dem Bau der Binary-Packages wird die Source-Package neu gebaut, so dass die im parent directory abgelegten Dateien der neuen Source und Binary-Packages die vollständige Arbeit abbilden. Es ist also im Normalfall ausreichend, diese Dateien zur Sicherung der geleisteten Arbeit irgendwo anders hinzuschieben, und es ist ohne weiteres möglich, die zu einer binary package gehörenden Sourcen eindeutig zu identifizieren.

Für den erfolgreichen Bau einer Package ist es notwendig, dass Library-Header und andere Dateien vorhanden sind. Da die Anforderungen von Package zu Package unterschiedlich sind, ist der Debian-Maintainer per Policy verpflichtet, zu dokumentieren, welche Packages installiert sein müssen, damit die Package erfolgreich gebaut werden kann.

Hierzu dienen die Felder Build-Depends: und Build-Depends-Indep: in debian/control.

Dieses Programm übernimmt den kompletten Bau einer Package. Es:

• bereinigt das lokale Environment,
• prüft, ob die build dependencies erfüllt sind und meckert wenn nicht
• putzt das Package Build Directory
• baut die Source Package neu,
• baut die Binary-Packages,
• ruft lintian auf den erzeugten Packages auf.

Debuild liest die lokale Konfigurationsdatei ~/.devscripts, die sinnvollerweise den folgenden Inhalt haben sollte:

DEBUILD_LINTIAN=no
DEBUILD_ROOTCMD=fakeroot
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc"

Wenn die Fehlermeldung “sh: debian/rules: /usr/bin/make: bad interpreter: Permission denied” erscheint, ist debian/rules nicht ausführbar: chmod 775 debian/rules.

Für den korrekten Bau der Source Package ist es notwendig, dass das .orig.tar.gz mit dem richtigen Namen im parent directory bereit liegt. Liegt es nicht dort bereit, wird die Package als Debian Native Package gebaut, was üblicherweise nicht im Sinne des Erfinders ist.

Der Packagename wird aus debian/control; die Versionsnummer aus debian/changelog gewonnen.

dch dient zur komfortablen Bearbeitung des Debian-Changelogs. In unserer Umgebung wird der erste Aufruf in einer neu zu backportenden Package fast immer dch -i lauten, wodurch eine neue Package-Version erzeugt wird. Durch Veränderung der Versionsnummer im changelog kann man die in die Dateinamen der Binary-Packages eingebaute Versionsnummer beeinflussen.

Das Makefile =debian/rules= steuert den kompletten Bau der Debian-Package. Es muss mindestens die folgenden Targets unterstützen:

• clean - Setzt die Package in einen definierten, sauberen Zustand zurück
• build - Compiled die Package
• binary - Baut das .deb

Man verwendet üblicherweise die Konstruktion fakeroot debian/rules foo.

In der Praxis braucht man direkte Aufrufe von debian/rules nur dann, wenn man auf der Suche nach einem Fehler in der Package ist. Das spart erheblich Zeit, da debian/rules build und debian/rules binary wie bei Makefiles üblich bereits erledigte Arbeit nicht wiederholen, während dpkg-buildpackage aus Gründen der Sauberkeit immer bei Null beginnt, bzw. die Package durch den Aufruf von debian/rules clean vor Beginn seiner Arbeit wieder auf den Nullpunkt zurücksetzt.

Wenn man den Fehler gefunden hat, sollte man deswegen die endgültig zur Verwendung bestimmte Package trotzdem mit dpkg-buildpackage oder debuild bauen.

In dieser Datei stehen Informationen über Source-Package und Binary-Packages, insbesondere die Dependencies für Bau- und Laufzeit.

In dieser Datei dokumentiert man Änderungen an der Package. Zusätzlich entnehmen die Packaging-Tools aus dem Changelog die Versionsnummer der zu bauenden Package für die zu erstellenden Hilfsdateien sowie den Namen des bauenden Maintainers.

• dpatch erwähnen
• mydebuild veröffentlichen (#226947)
• debinterdiff veröffentlichen