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