© adrianhancu, 123RF

Dpkg gilt als leistungsfähiger Paketmanager, und wer Ubuntu oder Debian nutzt, greift gern auf ihn zurück. Dieser Artikel verrät, wie Admins oder Entwickler effizient passende Debian-Pakete für die Installation von Programmen und Bibliotheken erstellen.

Anhand der Meldungen, die der Cloud-Hype in den vergangenen Jahren immer und immer wieder produziert, wären die klassischen Distributionen fast zu bemitleiden. Da klingt es so, als schickten sich Core OS & Co. an, ihnen den Garaus zu machen. Aufgeblähte Systeme mit vielen Paketen, so das Versprechen, solle es in Zukunft gar nicht mehr geben. Stattdessen liefe alles in Containern, auf minimalistischen Systemen, die außer Docker gar keine Software benötigen.

Die Realität sieht freilich anders aus: Auch heute noch setzen viele auf die klassischen Distributionen. Zwar hat jeder große Hersteller heute auch eine Mikrodistribution auf Basis des eigenen Enterprise-Systems im Sortiment; doch wer lieber ein Debian, ein Ubuntu, ein SLES oder ein RHEL installiert, wird kaum auf Unverständnis stoßen. Wer sich mit den genannten Distributionen etwas auskennt, kennt den einen großen Unterschied zwischen ihnen: Red Hat und Suse setzen auf den Red Hat Package Manager RPM. Debian nutzt Debian Package (Dpkg) und vererbt dies auch an sein Derivat Ubuntu.

Damit ist klar: Wer Software auf Systeme mit Debian oder Ubuntu bringen möchte, tut das am besten in Form von ».deb«-Paketen. Die zu bauen wirkt auf viele noch immer wie ein Buch mit sieben Siegeln. Dieser Artikel gibt Starthilfe: Das Ziel der Übung besteht darin, aus einem simplen Programm ein Debian-Paket zu machen.

Ohne Regeln geht es nicht

Das ».deb«-Paketformat ist kein Teufelswerk sondern technisch gut und sauber dokumentiert. Unter der Haube sind Debian-Pakete »ar«-Archive, die mehrere komprimierte Tarballs enthalten (Abbildung 1). Im so genannten Control-Tarball finden sich die Meta-Informationen des Pakets, Data enthält dagegen den Payload, also die zum eigentlichen Programm gehörenden Dateien.

Abbildung 1: Ein Debian-Paket ist ein »ar«-Archiv, das verschiedene komprimierte Tarballs enthält – dieses Format gibt »dpkg« vor.

Die simple Beschreibung des Paketformates genügt dem Admin noch nicht als Anhaltspunkt für den Paketbau – denn wer ».deb«-Pakete erstellen möchte, braucht mehr als nur die technische Spezifikation des ».deb«-Formats. Debian und folglich auch Ubuntu verfügen über komplexe Regelwerke, die den Betreuern von Paketen enge Vorgaben machen. Grundsätzlich gilt: Pakete, die offizieller Teil des Debian-Archivs werden sollen, müssen sich strikt an diese Regeln halten.

Die Bibel der Paketbetreuer ist die Debian Policy [1], und das Gotteslob ist die Developers’ Reference ([2], [3]). Wer nicht vorhat, Pakete in das Debian-Archiv hochzuladen, kann auch ».deb«-Pakete bauen, die diesen Regelwerken nicht entsprechen. Gewonnen wäre damit aber nichts, denn die diversen Vorgaben existieren ja nicht, um Debian-Maintainer zu ärgern. Stattdessen sorgen sie als übergreifender Standard dafür, dass Debian-Systeme gewissen Qualitätsanforderungen genügen. Es ist deshalb sinnvoll, auch beim Bau eigener ».deb«-Pakete die Regeln sehr genau zu befolgen.

Ein schlimmer Hack

Bevor es allerdings um echte ».deb«-Pakete geht, erscheint es zuerst sinnvoll, Equivs vorzustellen. Das Szenario, für das dieses Toolset erfunden wurde, kommt manchem Admin sicher bekannt vor: Man möchte ein Paket aus dem Debian-Archiv installieren, das eine bestimmte Abhängigkeit hat.

Aus irgendeinem Grund will der Admin die abhängigen Pakete aber nicht unmittelbar aus dem Debian- oder Ubuntu-Archiv installieren. Ein Grund dafür könnte sein, dass er lokal eine andere Version der Software nutzt als jene, die ursprünglich als ».deb«-Paket im Debian-Archiv zu finden war. Um sich bei der Installation des gewünschten Pakets nicht die lokale Installation zu zerschießen, ist Equivs ein sehr nützliches Werkzeug.

Im Grunde generiert Equivs eine Kontrolldatei (»control«), wie sie auch ein normales »Paket enthält, und erzeugt daraus ein valides ».deb«-Paket. Der »data«-Tarball in diesem Paket ist jedoch leer, eben weil die Software ja bereits an »dpkg« vorbei ausgerollt ist.

Konkret funktioniert das so: Zunächst installiert der Admin das Paket »equivs«. Danach legt der Befehl »equivs-control Paketname« die benötigte Kontrolldatei als Template an. Öffnet der Admin es auf der Konsole, begegnen ihm darin viele Zeilen – von denen allerdings nur acht wirklich nötig sind: »Section«, »Priority«, »Standards-Version«, »Package«, »Version«, »Maintainer«, »Architecture« sowie »Description«.

Die meisten der Schlüsselwörter begegnen dem Admin später auch beim Bau tatsächlicher Debian-Pakete – nur »Version« ergibt sich dort aus dem Changelog. Die vorgegebenen Werte bleiben in dem von »equivs-control« generierten File unangetastet, sofern die Bearbeitung nicht offensichtlich nötig ist – etwa bei »Package« und »Maintainer«.

Danach baut der Befehl »equivs-build Kontrolldatei« aus der Datei ein ».deb«-Paket, das sich per »dpkg -i« installieren lässt. Fertig ist der Lack – das ursprünglich gewünschte Debian-Paket ist nun per »apt-get« wie üblich installierbar. Allerdings: Der beschriebene Vorgang ist ein kruder Hack und sollte nur in absoluten Ausnahmefällen zur Anwendung kommen. Sinnvoller ist es, ein echtes ».deb«-Paket zu bauen.

Aller Anfang

Unter alten Hasen im Debian-Geschäft ist es eine Binsenweisheit, dass der größte Teil der Paketierarbeit stattfindet, bevor die erste Konsole auch nur geöffnet ist. Denn das ».deb«-Paket zu erstellen ist am Ende eine triviale Aufgabe, wenn man weiß, wie der produzierte Output des Programms entlang den Debian-Regeln zu verpacken ist. Es empfiehlt sich deshalb dringend, ein paar zentrale Fragen bereits zu beantworten, bevor es mit der Verpackerei losgeht.

Die wichtigste Frage ist, welche Art von Software der Admin überhaupt verpacken möchte. Handelt es sich um ein einzelnes Programm oder eine Bibliothek? Produziert ein Quellcode mehrere Binärdateien, die in dasselbe oder in unterschiedliche ».deb«-Pakete gehören? Davon hängt ab, wie komplex das Paketieren ist.

Sind die wichtigsten Fragen geklärt, kommt dem Admin ein praktisches Helferlein gerade recht: »dh-make«. DH steht in diesem Kontext für Debhelper, eine Sammlung von Programmen, die Admins das Pflegen von Software erleichtern und es zudem standardisieren. Die Debhelper-Werkzeuge sind in der Debian-Community mittlerweile zum Quasi-Standard geworden, weshalb sie sehr ausgereift und erprobt sind. Gerade Paketierneulinge tun aus diesem Grund gut daran, auf sie zu setzen.

»dh-make« ist dafür ein perfektes Beispiel. Damit aus einem Ordner mit den entpakten Quellen eines Programms ein ».deb« werden kann, ist ein Unterordner »debian« nötig (Abbildung 2), den die Bauwerkzeuge von Dpkg nutzen und aus dem sie alle benötigten Informationen beziehen. »dh-make« legt ein entsprechendes Verzeichnis für den Admin an und versucht so viele Werte wie möglich auf Basis von Umgebungsinformationen automatisch herauszufinden.

Abbildung 2: Im »debian«-Unterverzeichnis innerhalb des Programm-Quelltexts liegen alle Dateien, die für die Paketerstellung nötig sind

Wo das nicht klappt, legt der Admin anschließend Hand an und editiert die Dateien so, dass es passt. Im Anschluss baut das Kommando »dpkg-buildpackage« das Paket – fertig! Was einfach und simpel klingt, ist es auch.

Grundsätzliches

Gegeben sei also ein Beispielprogramm, etwa GNU Hello, aus dem der Admin ein Debian-Paket bauen möchte. Zunächst lädt er sich dafür den Tarball vom Hersteller herunter, den der im Debian-Sprech üblicherweise “Upstream” nennt. Danach entpackt er den Tarball, und zwar so, dass das Verzeichnis den Namen »hello« sowie – mit einem »-« verbunden – die Versionsnummer zeigt, etwa »hello-2.10«. Durch die korrekte Benennung des Ordners ermöglicht es der Admin »dh-make«, die richtige Versionsnummer herauszufinden.

Obendrein stellt der Admin sicher, dass der originale Tarball im selben Verzeichnis wie der entpackte Quelltext komprimiert vorliegt. Der Name ist allerdings anders als bei den meisten anderen Upstreams zu ermitteln – er folgt dem Schema »name_version.orig.tar.gz/bz2/xz«, im Beispiel also entsprechend »hello_2.10.orig.tar.gz«.

Das Beispiel »hello« produziert lediglich eine Binärdatei sowie eine Manpage und eine Info-Datei, die allesamt in dasselbe Binärpaket gehören. Dies steht unter der GPLv3 und legt zuverlässig ein passendes »debian«-Verzeichnis für »hello« an – es ist auf den meisten Systemen aber von Haus aus gar nicht installiert.

Grundsätzlich tut der Admin gut daran, ein paar grundlegende Pakete auf die Platte zu holen, wenn er auf diesem System Debian-Pakete bauen will. Denn zwar gilt die Regel, dass Debian-Pakete in ihrer Kontrolldatei Abhängigkeiten explizit deklarieren müssen, die für ein erfolgreiches Kompilieren vorgeschrieben sind. Ein paar Ausnahmen von dieser Regel existieren allerdings dennoch. Besonders zu erwähnen sind dabei die Pakete »build-essential«. Ferner sollte der Admin die Pakete »debhelper«, »dh-make«, »quilt«, »fakeroot«, »devscripts« sowie »lintian« installiert haben.

Danach geht es los mit dem »debian«-Ordner für »hello«: Indem der Admin die beiden Umgebungsvariablen »DEBFULLNAME« und »DEBEMAIL« setzt, verrät er »dh-make« die entsprechenden Werte für die Kontrolldatei und das Changelog des späteren Debian-Pakets.

Grundsätzlich sollte er diese Parameter in der eigenen ».bashrc« definiert haben. Denn wenn er später das Paket auf eine neue Version aktualisieren will und dafür »dch« nutzt, um für die neue Version einen Eintrag im Changelog des Debian-Pakets zu erstellen, bedient sich auch dieses vollautomatisch der Werte in eben jenen Variablen. Vorausgesetzt freilich, sie sind dort auch gesetzt. Beispiele wären etwa “Martin Loschwitz” für »DEBFULLNAME« und »madkiss@ debian.org« für »DEBEMAIL«.

Das Fundament gießen

Danach geht die Party los – und »dh-make« verfügt sogar über einen interaktiven Modus, in dem der Admin wichtige Details nachreicht, falls das Programm sie selbst nicht erkennen kann. Aus dem Verzeichnis der entpackten Quellen heraus führt der Admin »dh-make -f ../hello_2.10.orig.tar.gz« aus, um diesen interaktiven Assistenten zu starten. Bei der ersten Frage möchte »dh-make« wissen, wie viele Pakete das Source-Paket hervorbringt; wie eingangs bereits erwähnt handelt es sich in dem Beispiel um ein typisches Single-Binary-Paket, sodass die korrekte Antwort »s« lautet.

Die Vielzahl der Auswahlmöglichkeiten lässt hier bereits vermuten, dass Debian-Pakete auch hochgradig komplex sein können. Wollte man alle Optionen im Rahmen eines Artikels besprechen, entstünde wohl eher ein Sonderheft. Dieses Beispiel bedient sich deshalb des simpelsten Ansatzes, geht später aber auf Bibliotheks-Pakete noch kurz ein.

Wenn »DEBFULLNAME« und »DEB-EMAIL« gesetzt sind, sollte »dh-make« außer der Frage nach dem Paket-Typ keine Fragen mehr stellen. Denn die Lizenz muss in der »copyright«-Datei des Pakets zwar vermerkt sein, aber »dh-make« erkennt verschiedene Standard-Lizenzen automatisch, wenn sie im Quelltext als »LICENSE« oder »COPYING« vorliegen. Das ist bei »hello« der Fall.

Die von »dh-make« angezeigte Übersicht bestätigt der Admin per Eingabetaste – kurze Zeit später findet sich ein Ordner namens »debian« im entpackten Sourcecode. Und das ist bereits mehr als die halbe Miete.

Aufräumen und korrigieren

Wechselt der Admin nun in jenes Verzeichnis, findet er darin eine ganze Reihe von Dateien mit »ex« oder »EX« im Namen. Das sind alles Beispiele für verschiedene Konfigurationsdateien für »Debhelper«-Skripte, die bei entsprechenden Programmen zur Anwendung kommen könnten. Exemplarisch sei »watch.ex« genannt, mit dem sich per GNU Watch automatisch prüfen lässt, ob von einem Programm eventuell bereits eine neuere Version verfügbar ist.

Es gibt auch Beispiele für Systemd-Units und für etliche andere Kuriositäten, die nötig werden, wenn ein gebautes Programm etwa einen Daemon startet. Im Falle von GNU Hello ist das aber alles ganz und gar überflüssiger Ballast. Um »debian« sauber zu halten, empfiehlt es sich deshalb, alle Dateien bis auf die mit den Namen »control«, » changelog«, »compat«, »rules« und »source« zu löschen – denn das sind die einzigen, die für das simple Debian-Paket im vorliegenden Beispiel notwendig sind.

Das Changelog

Jedes Debian-Paket enthält ein Changelog. Das bezieht sich aber nicht auf das Programm des Pakets, sondern auf das Paket selbst und führt die durch den Paketbetreuer vorgenommenen Änderungen auf. »dh-make« hat die initiale Version des Changelog bereits angelegt und dank der gesetzten Variablen »DEBEMAIL« und »DEBFULLNAME« auch entsprechend zuvor ausgefüllt.

Wer möchte, entfernt in »changelog« noch das »Closes #…« aus der Zeile, in der »Initial Release« steht – denn die ist ein Debian- und Ubuntu-Spezifikum: Zu jedem neuen Paket muss es bei beiden Distributionen einen Eintrag im Bugtracker geben. Dieser Eintrag heißt bei Debian etwa »ITP« (Intent to Package). Lädt der Admin das Paket dann tatsächlich ins Archiv hoch, kann er den zuvor geöffneten “Bug” per Changelog des Pakets wieder schließen. Auf das konkrete Beispiel trifft das aber nicht zu – zumal GNU Hello in Debian bereits existiert.

Die Kontrolldatei “control”

Weiter geht es mit der zentralen Paketdatei »control« (Abbildung 3). In ihr ist verzeichnet, welche Binärpakete das Quellpaket »hello« hervorbringt. »dh-make« hat die Datei bereits vorausgefüllt, der paketierende Admin tut aber gut daran, sie trotzdem im Detail zu begutachten – denn manche Felder sind bisher leer. Etwa »Section«, wo er eine Sektion vermerken kann, in die das Paket fiele, würde er es offiziell ins Archiv der Debian-Pakete hochladen.

Abbildung 3: Zum Vergleich hier die »control«-Datei des Debian-Pakets von GNU Hello, wie sie im offiziellen Debian-Archiv liegt.

Eine Liste der Sektionen findet sich unter [4], und weil GNU Hello der Ausbildung dient, könnte man etwa »education« nehmen. Das offizielle Paket von GNU Hello ist bei Debian allerdings in »devel« einsortiert, weil es ein Beispiel für Entwickler ist (Abbildung 4).

Abbildung 4: Das Debian-Archiv ist in viele Sektionen unterteilt – welche für das eigene Paket die richtige ist, lässt sich manchmal schwer herausfinden.

Bei »Maintainer« fügt der Admin seinen Namen sowie seine E-Mail-Adresse ein, die Syntax entspricht »Name E-Mail«. »Vcs-Git« und »Vcs-Browser« sind Sonderdirektiven für Pakete, die Teams betreuen. Dort hinterlegen die Betreuer Links zu jenem Git, in dem sie »debian« pflegen. Bei »Homepage« trägt der Betreuer hingegen den Link zur Upstream-Website ein. Schließlich fehlen noch die »Description« und direkt darunter die lange Beschreibung. Hier tut der Admin gut daran, eine aussagekräftige, wenn auch kurze Beschreibung zu hinterlegen – denn so dokumentiert er den Grund dafür, dass er das Paket überhaupt gebaut hat, auch für andere.

Compat- bis Copyright-Datei

Besonders leicht gestaltet sich das Bearbeiten von »compat«, denn es entfällt. Die Datei ist für Debhelper notwendig, jene schon erwähnte Sammlung von Helferlein für Paketbetreuer. »dh-make« hat sie angelegt, der Admin muss sie in aller Regel gar nicht bearbeiten.

Etwas umständlicher wird es bei der Datei »copyright«. Debian setzt hier seit einigen Jahren auf ein maschinenlesbares Format, das in der ersten Zeile der Datei auch referenziert ist. Darunter stehen der Upstream-Name des Programms sowie die URL zum Quelltext.

Dann geht es mit Einzelabschnitten weiter, in denen zunächst die Copyright-Angaben für einzelne Dateien stehen, bevor am Ende die Kurzfassung der genutzten Lizenzen kommt. Bei GNU Hello ist das noch ziemlich simpel, denn das Tool steht einheitlich im Copyright der Free Software Foundation. Größere Programme oder Bibliotheken, zu deren Quelltext viele Entwickler über viele Jahre hinweg beigetragen haben, sind deutlich schwerer zu erfassen, weil die Copyright-Vermerke hier zum Teil in jeder einzelnen Datei stehen.

Wichtig: In »copyright« muss auch das Copyright für »debian/« verzeichnet sein – das vergessen viele Admins gerne mal. Wer Details zum Format der Copyright-Datei benötigt, liest die Dokumentation, die die erste Zeile der Datei verlinkt.

Das Rules-Makefile

Dreh- und Angelpunkt des Bauvorgangs ist »rules«. Die Datei ist ein Makefile und hat entsprechend auch »make« im Shebang stehen – bei einem simplen Werkzeug wie GNU Hello genügt in aller Regel jedoch eine einzelne Zeile, die sich auf Debhelper bezieht und die »dh-make« auch entsprechend angelegt hat.

Hier wird deutlich, wie mächtig Debhelper ist: Weil die meisten Tools und Bibliotheken heute auf die GNU Autotools setzen, lassen sich mit dem berühmten Dreisprung aus »configure«, »make« und »make install« alle notwendigen Schritte abarbeiten. Und genau das macht Debhelper sich effektiv zunutze.

Was freilich noch lange nicht bedeutet, dass es bei komplexeren Paketen nicht auch deutlich komplexere »rules«-Dateien gibt. Wer glaubt, eine eigene Datei für die Bauregeln anlegen zu müssen, hält sich idealerweise an die Dokumentation von GNU Make. Die Build-Targets, die jedes Paket haben muss, sind zudem in der Dokumentation für Paketbetreuer aufgelistet.

Zudem lohnt es sich vermutlich auch, die Debhelper-Dokumentation zu konsultieren – denn wer nur einzelne Details am vorgesehenen Debhelper-Automatismus verändern möchte, arbeitet besser mit den diversen »override_dh«-Targets in »rules«, anstatt die gesamte Datei gleich selbst anzulegen. Mit jenen Targets lassen sich einzelne Bauziele in »rules« abändern (Abbildung 5).

Abbildung 5: Die »rules«-Datei ist ein Makefile. Wer einzelne Direktiven von Debhelper überschreiben will, tut das per »dh_override«-Target.

Das erste Paket

Damit ist der Zeitpunkt gekommen, an dem sich das erste Debian-Paket für GNU Hello erstellen lässt. Im Quelltext – nicht im »debian«-Ordner – ruft der Admin dazu den Befehl »dpkg-buildpackage -rfakeroot -uc -us« auf. Wenige Sekunden später liegt in der übergeordneten Verzeichnisebene das fertige ».deb«-Paket. Herzlichen Glückwunsch – so ganz fertig ist die Arbeit aber noch nicht.

Lintian als Aufpasser

Zumindest sollte der Admin sein Paket nämlich noch mit »lintian« überprüfen. Dazu ruft der das Kommando

lintian -EvIm --pedantic --show-overrides --color=auto *changes

in dem Ordner auf, in dem auch die ».deb«-Datei liegt. Jene Datei generiert »dpkg-buildpackage« automatisch, sie ist also zuverlässig vorhanden, wenn der Bauvorgang geklappt hat.

Lintian zeigt zwei Arten von Befunden an: Zeilen, die mit »W« beginnen, sind Warnungen zu möglichen Policy-Verstößen. Zeilen, die mit »E« beginnen, sind solche Fehler, die Lintian zuverlässig erkannt zu haben glaubt. Jene sollte der Admin auf jeden Fall ausmerzen, bevor er das Paket auf einem System zum Einsatz bringt.

Die Maintainer-Skripte

Wer das entstandene ».deb«-Paket nun per »ar x« auspackt und einen Blick in den »control«-Tarball wirft, findet dort neben der »control«-Datei auch eine Datei namens »postinst«. Wo kommt die her und was hat es mit ihr auf sich? Keine Panik: Es handelt sich um ein so genanntes Maintainer-Skript, und die sind im Paket-Alltag absolut wichtig.

Es kommt regelmäßig vor, dass ein Admin auf einem Zielsystem unmittelbar vor oder nach der Installation oder vor oder nach dem Löschen eines Pakets Befehle ausführen muss. Das klassische Beispiel ist ein Daemon, der nach der Installation gestartet und vor dem Löschen gestoppt werden soll. Für die vier genannten Einsatzszenarien gibt es »preinst«, »postinst«, »prerm« und »postrm«. Es handelt sich um ordinäre Shellskripte.

Vorsicht: Wer Debhelper nutzt und eigene Maintainer-Skripte schreibt, muss unbedingt »#DEBHELPER#« im Skript lassen – dort fügen die Debhelper-Werkzeuge dann ihre Modifikationen ein.

Produziert ein Source-Paket nur ein Binärpaket, kann der Admin die für die Maintainer-Skripte benötigten Dateien als »debian/Skript« ablegen, also etwa »debian/postinst«. Produziert das Source-Paket mehrere Binaries, lautet der korrekte Name »debian/Paketname.postinst« oder analog für andere Skripttypen.

Bibliotheken richtig paketieren

Apropos Quelltext-Pakete, die mehrere Binary-Pakete erzeugen: Wie ist der Umgang mit ihnen aus Sicht der Debian-Richtlinien korrekt? Weil das klassische Beispiel für eine solche Situation Bibliotheken sind, lohnt es sich, eben dort genauer hinzuschauen. Wer konsequent Debhelper nutzt, wird schnell merken, dass Multi-Binärpakete gar nicht viel schwieriger zu pflegen sind als solche, die nur ein Binärpaket erzeugen.

Laut Policy gilt: Eine Bibliothek muss in wenigstens zwei Pakete geteilt werden – nämlich das Paket, das die tatsächliche Bibliothek enthält (in aller Regel »libIrgendwas«) sowie ein Paket, das die Headerdateien sowie alle Dateien enthält, die für Entwicklung mit der Bibliothek notwendig sind. Das geschieht, um den Plattenplatz auf den Systemen der Nutzer nicht unnötig zu verschwenden.

Wer dieses Konstrukt in Debian abbilden will, editiert zunächst wie gehabt »debian/control« und sorgt dafür, dass für jedes Paket ein entsprechender »Package«-Block vorhanden ist. Um eine Bibliothek mit »dh-make« zu paketieren, genügt es, einfach »Library« beim Pakettyp zu wählen, und heraus kommt ein entsprechendes Template.

Während des Bauvorgangs wird Debhelper wie gewohnt den bekannten Dreischritt aus »configure«, »make« und »make install« vollziehen – dabei wird es jedoch ein temporäres Zwischenverzeichnis angeben, in dem zunächst erst einmal alle installierten Dateien landen. Im Anschluss daran ruft es das Tool »dh_install« auf, um alle Dateien damit in die jeweiligen Ordner der künftigen Pakete zu verschieben.

Seitens des Admin lässt sich der Prozess durch das Anlegen entsprechender »Paketnameinstall«-Dateien in »debian« beeinflussen. Wer nicht weiß, welche Dateien eine Bibliothek überhaupt produziert, kann den Dreischritt auch selbst ausführen und bei »configure« per »–prefix=Ordner« einen lokalen Ordner angeben. Nach »make install« finden sich dann alle Dateien in jenem Ordner, sodass der Admin in Ruhe die Dateien in »debian« für sie anlegen kann.

Das Paket aktualisieren

Möchte der Admin sein Debian-Paket zu einem späteren Zeitpunkt etwa auf eine neue Version aktualisieren, ist das gar kein Problem. Dazu lädt er den neuen Quelltext herunter, achtet auf dessen korrekte Benennung und entpackt ihn in ein ebenfalls analog zu den genannten Regeln benanntes Verzeichnis.

Danach kopiert der den bestehenden »debian«-Ordner aus dem alten Paket in den neuen Quelltext. Wenn »DEBFULLNAME« und »DEBEMAIL« gesetzt sind, reicht ein simples »dch -i«, um einen neuen Changelog-Eintrag zu erstellen. Die Versionsnummer darin ist ebenso anzupassen wie der eigentliche Changelog-Eintrag. Danach genügt »dpkg-buildpackage«, um das Paket in einer neuen Version zu erstellen.