Debian-Pakete erstellen

Dieser Artikel soll eine kurze Einführung über den Aufbau und die Erstellung von Debian-Binary-Paketen als auch -Source-Paketen liefern. Es wird hier nur auf die Grundlagen eingegangen, für eine ausführliche Erklärung verweise ich auf https://www.debian.org/doc/manuals/maint-guide/ .

Ein Binary-Paket kann direkt installiert werden. Auch wenn der Ausdruck Binary-Paket (oder Binärpaket) impliziert, dass ein kompiliertes Programm enthalten ist, muss das nicht der Fall sein. Ein Binärpaket kann auch nur Skripte enthalten, wodurch es nicht an eine bestimmte Hardware-Architektur gebunden sein muss.

Ein Source-Paket (oder Quellpaket) enthält den Quellcode und die Bauanweisungen für ein oder mehrere Binary-Pakete.

Namenskonvention

Die Konvention für den Paketnamen ist: paketname_[epoch:]version[-revision]_architektur. Die zwei Unterstriche (_) trennen Paketname, Version und Architektur. Klicke hier für Details und hier speziell für die Versionsnummer.

• paketname: Der Name des Paketes
• epoch (Versionsschema - optional): Falls sich das Versionierungsschema ändert (z.B.: Änderung von Datums- (bspw. YYYYMMDD) zu Semantic-Versioning (<MAJOR>.<MINOR>.<PATCH>) oder Fehler in der alten Versionierung), kann eine Versionsnummer - praktisch begonnen bei 1 (da 0 angenommen wird, wenn nicht angegeben - in dem Fall war die Angabe von epoch nicht notwendig) - gefolgt von einem Doppelpunkt (:) als Präfix für die Version verwendet werden. Somit wird sichergestellt, dass eine neue Version auch als aktueller interpretiert werden kann, wenn sich das Schema ändert.
• version: Eine vergleichbare Zeichenkette, welche die Unterscheidung von älteren zu neueren Versionen erlaubt.
• revision (optional): Wenn z.B. ein (fremdes) existierendes Projekt verpackt wird, auf das ein Patch angewendet wird, für den es (noch) keine neue Upstream-Version gibt oder geben wird, wird als Suffix ein Bindestrich (-) gefolgt von einer Zahl an die Version angefügt. Praktisch wird auch hier wieder bei 1 begonnen, da ohne Angabe 0 impliziert wird.
• architektur: z.B.: armhf, arm64, amd64 oder all

Minimaler Aufbau des Arbeitsverzeichnisses für ein Binary-Paket

Das Arbeitsverzeichnis sollte gemäß der #Namenskonvention benannt werden.

Neben den Dateien, die schlussendlich auf dem Zielsystem installiert werden sollen, ist nur eine einzige Steuerdatei notwendig (siehe #DEBIAN/control (Binary-Pakete)): control. Diese Datei (und eventuelle weitere Steuerdateien und Metadaten) muss in <ARBEITSVERZEICHNIS>/DEBIAN/ liegen. Die restlichen Dateien müssen einfach in einer Struktur abgelegt werden, die das Root-Verzeichnis des Zielsystems relativ im Arbeitsverzeichnis darstellt.

Ein Beispiel:

 hallo-welt_1.0_all/
 |
 ├── DEBIAN/
 |   └── control
 |
 └── usr/
     └── local/
         └── bin/
             └── hallo-welt

Minimaler Aufbau des Arbeitsverzeichnisses für ein Source-Paket

Das Arbeitsverzeichnis eines Source-Paketes braucht zwar mehr Steuerdateien als ein Binary-Paket, allerdings ist hier im Wesentlichen nur die Struktur des debian-Unterordners wichtig, da die Installationspfade durch das Buildsystem bestimmt werden. Zu beachten ist, dass im Gegensatz zum Binary-Paket debian kleingeschrieben wird.

Ein Beispiel:

 helloworld-1.0/
 |
 ├── debian/
 |   ├── changelog
 |   ├── control
 |   ├── rules
 |   └── source/
 |       └── format
 |
 ├── Makefile
 └── helloworld.c

Control Files

debian/compat

Diese Datei enthält nur eine Zeile mit einer Zahl, welche die debhelper-Kompatibilitätsstufe festlegt.

Diese Datei sollte in aktuellen Projekten nicht mehr benutzt werden - stattdessen sollte im Build-Depends-Feld der control-Datei debhelper-compat (= 13) aufgeführt werden (v13 ist der aktuell empfohlene Modus - siehe man debhelper-compat-upgrade-checklist).

debian/source/format

Diese Datei enthält nur eine Zeile, in welchem das Format des Source-Paketes angegeben wird.

Die zwei aktuell relevanten Formate sind:

• 3.0 (quilt): Wenn eine Patch-Verwaltung notwendig ist, um Änderungen zum Upstream-Code zu verwalten, muss dieses Format gewählt werden
• 3.0 (native): Sollte für Pakete verwendet werden, deren Quellcode speziell für Debian geschrieben wurde, und deshalb keine Patch-Verwaltung braucht.