AA_baustelle_sxc481611_AlexanderRist.jpg

© Alexander Rist, sxc.hu

Baustelle

Debian-Pakete selbst erstellen

17.07.2013
Die leistungsfähigen Tools, mit denen Debian-Entwickler Pakete bauen, stehen auch Normalanwendern offen. Oft spart ihr Einsatz gegenüber dem Kompilieren per Hand sogar Aufwand.

Serie: Pakete im Eigenbau

RPM-Pakete im Eigenbau LU 07/2013, S. 88 http://www.linux-community.de/28508
DEB-Pakete im Eigenbau LU 08/2013, S. ### http://www.linux-community.de/28514
Arch-Linux-Pakete im Eigenbau LU 09/2013

Keine Distribution bietet ihren Nutzern mehr Pakete als Debian. So ist es fast selbstverständlich, dass dafür auch ein ausgefeiltes System zum Bauen von Paketen bereitsteht. Wie sein Gegenstück auf RPM-basierten Systemen automatisiert es sowohl das Kompilieren aus dem Quelltext als auch das eigentliche Erstellen des Pakets. Wie immer beim Kompilieren aus den Quellen fällt die Bindung an eine bestimmte Systemversion viel geringer aus als bei vorgefertigten Binärpaketen.

Keimzelle

Um das Debian-Build-System unter Ubuntu oder Debian zu nutzen, installieren Sie zunächst die Pakete build-essential, debhelper, dh-make, quilt, fakeroot und devscripts. Dann exportieren Sie zwei Umgebungsvariablen mit Ihrer E-Mail-Adresse und Ihrem Namen (Listing 1). Am besten fügen Sie diese Befehle Ihrer .bashrc hinzu.

Listing 1

export DEBMAIL="adresse@domain.tld"
export DEBFULLNAME="Vorname Nachname"

Sowohl für Debian als auch für Ubuntu liegen die Quellpakete in eigenen Repositories, die Sie in /etc/apt/sources.list am Schlüsselwort deb-src am Zeilenbeginn erkennen. Nach der Installation sind die Quellcode-Repositories standardmäßig aktiviert. Der Befehl apt-get source Name lädt die Quellen für das Paket Name in das aktuelle Verzeichnis herunter.

Das Arbeiten mit Root-Rechten sollten Sie vermeiden, da Sie die Dateien Name_Version.orig.tar.gz, Name_Version.debian.tar.gz und Name_Version.dsc als normaler Anwender weiterverarbeiten. Zu den genannten Dateien kommen oft noch Patches mit der Endung .diff.gz, die vor dem Kompilieren Fehler im Quellcode bereinigen. Die Datei mit der Endung .orig.tar.gz fehlt dagegen bei Paketen, bei denen die Debian-Maintainer den Quellcode selbst betreuen und zu denen daher kein Upstream existiert. Wenn die Upstream-Maintainer eines Programms dagegen die Quellen gleich in "debianisierter" Form ausliefern, also inklusive eines den Paketbau steuernden debian/-Unterverzeichnisses, fehlt Name_Version.debian.tar.gz.

Mit apt-get source entpacken Sie die Tarballs in das Verzeichnis Name_Version. Haben Sie die Debian-Quellpakete von Launchpad [1] heruntergeladen, verwenden Sie stattdessen dpkg-source -x Name_Version.dsc zum manuellen Auspacken. Ein Aufruf von dpkg-buildpackage -uc -us aus dem entpackten Quellverzeichnis heraus genügt, um die Software zu kompilieren und in ein mit Dpkg installierbares Binärpaket einzubinden. Beim ersten Aufruf mahnt dpkg-buildpackage oft noch die Installation einiger Devel-Pakete an.

Ein erneuter Aufruf nach dem Einspielen der Abhängigkeiten sollte bei Paketquellen aus der laufenden Distribution immer mit einem funktionieren DEB-Paket enden, solange sich die Grundkomponenten des Systems (Bibliotheken, Compiler) noch im Auslieferungszustand befinden. Es lohnt sich, dpkg-buildpackage an einem beliebigen Quellpaket aus der laufenden Linux-Distribution auszuprobieren, um einmal die Meldungen eines erfolgreichen Bauvorganges durch das Konsolenfenster laufen zu sehen. Sie erkennen ihn an Zeilen wie dpkg-deb: Paket »Name« wird in "../Name_Version_i386.deb" gebaut gegen Ende der Konsolenausgabe.

Beispielhaft

Den Charakter einer Fingerübung verliert der Buildpackage-Aufruf, sobald Sie damit Pakete bauen, die für das laufende System nicht installationsfertig zur Verfügung stehen. So ist Ffdiaporama [2], ein Programm zum Erzeugen von Multimedia-Shows, nicht im Repository für Ubuntu 12.04 enthalten. Für Ubuntu 12.10 und 13.04 gibt es Pakete, wie immer bei offiziellen Ubuntu-Paketen mit zugehörigen Quellpaketen [3]. Wir wollen sehen, ob die Paketquellen für Ubuntu 12.10 sich auch unter Ubuntu 12.04 kompilieren lassen. Ohne diesen Umweg kann man das Paket aus der neueren Ubuntu-Version nämlich wegen einer nicht erfüllbaren Abhängigkeit nicht installieren.

Generell gilt:Die Voraussetzungen für das Übersetzen aus den Quellen sind deutlich weniger restriktiv als die binären Abhängigkeiten eines auf ein bestimmtes System zugeschnittenen Programms. So gibt es beispielsweise keine Bindung an eine Architektur (i386, x86_64). Auch der Austausch zwischen Debian und Ubuntu klappt oft reibungslos, denn der Löwenanteil der Ubuntu-Pakete übernimmt die Quellen aus Debian "Unstable".

Die Ffdiaporama-Paketquellen erreichen Sie auf der Launchpad-Seite [3] im Abschnitt Packages in Distributions (Abbildung 1). Unter "ffdiaporama" source package in Quantal finden Sie die Dateien ffdiaporama_1.3-1.dsc, ffdiaporama_1.3.orig.tar.gz und ffdiaporama_1.3-1.debian.tar.gz, die Sie in ein gemeinsames Verzeichnis herunterladen. Der Aufruf dpkg-source -x ffdiaporama_1.3-1.dsc entpackt die Quellarchive. Aus dem dabei entstandenen Verzeichnis ffdiaporama-1.3 heraus aufgerufen baut dpkg-buildpackage -uc -us ein auf Ubuntu 12.04 zugeschnittenes Paket. Da es sich um ein umfangreiches Programm handelt, dauert das Kompilieren ein wenig.

Abbildung 1: Launchpad ist eine speziell auf die Ubuntu-Entwicklung zugeschnittene Software-Plattform. Zu fast allen gehosteten Projekten gibt es Debian-Paketquellen, oft auch Binärpakete.

Aus den Debian-Quellen lassen sich also mit zwei Kommandozeilenaufrufen vollautomatisch auf dem laufenden System installierbare Binärpakete bauen. Stammen die Quellen nicht aus Ihrer Distribution selbst, ist der Erfolg dabei keineswegs garantiert: Möglicherweise testeten die Programmentwickler ihren Quellcode nie mit den dort vorhandenen Bibliotheks- oder Compiler-Versionen. Oft kompilieren aber auch systemfremde Debian-Quellen so reibungslos wie bei Ffdiaporama.

Vor allem aber lässt sich das erzeugte Debian-Paket, sollte es nicht funktionieren, wieder gefahrlos deinstallieren oder gegebenenfalls durch die bei der Distribution mitgelieferte Version ersetzen. Der Paketmanager verhindert dabei das Überschreiben von Dateien aus anderen Paketen. Wer also gewöhnliche Anwendungsprogramme installiert, braucht nicht zu fürchten, sein System zu beschädigen. Lediglich der Austausch von Systemkomponenten bleibt trotz Paketmanagement riskant.

Alles neu

Allerdings handelt es sich bei Version 1.3 von Ffdiaporama, für die wir gerade ein Ubuntu-12.04-Paket erstellt haben, nicht mehr um das aktuellste Release. Zum Glück ist aber das Debian-Build-System, mit dessen Hilfe ja die Debian- und Ubuntu-Maintainer viele tausend Pakete aktuell halten, auf ein schnelles Update der paketierten Programmversionen getrimmt. Laden Sie dafür von der Homepage des Programms den Quelltext für Ffdiaporama 1.5 [4] in das gleiche Verzeichnis, in dem sich auch schon die Quellen für Version 1.3 befinden.

Innerhalb des Ordners debian/ liegt ein Unterverzeichnis patches/. Da die darin enthaltenen Fixes für eine neue Programmcode-Version meist nicht mehr funktionieren (und oft auch nicht mehr nötig sind), löschen Sie den Unterordner. Wie Sie Patches reversibel deaktivieren, beschreibt der "Debian New Maintainers' Guide" [5]. Rufen Sie danach aus ffdiaporama-1.3/ heraus folgenden Befehl auf:

$ uupdate -v 1.5 ../Fffdiaporama_1.5.tar.gz

Dann wechseln Sie dann in das Verzeichnis ../ffdiaporama-1.5/, das der Update-Prozess erzeugt hat. Hier liegen der Quellcode von Ffdiaporama 1.5 sowie das Unterverzeichnis debian/ aus ffdiaporama-1.3/. Wenn sich am Bauprozess des Programms zwischen Version 1.3 und 1.5 nichts Wesentliches geändert hat, bestehen gute Chancen, dass dpkg-buildpackage -uc -us störungsfrei durchläuft und ein Paket für Ffdiaporama 1.5 baut.

Ganz so glatt geht es im Beispiel jedoch nicht über die Bühne: Das Kompilieren bricht mit der Meldungen ../engine/cDeviceModelDef.h:48:38: schwerwiegender Fehler: libavdevice/avdevice.h: Datei oder Verzeichnis nicht gefunden ab. Wenn der Compiler – wie hier – eine Header-Datei (Dateiendung .h) nicht findet, heißt das, dass ein benötigtes Devel-Paket fehlt. Zum Glück lässt sich leicht herausfinden, um welches es sich handelt.

Installieren Sie apt-file, falls es auf Ihrem System noch fehlt, und bringen Sie dessen Datenbank mit apt-file update als Root auf den neuesten Stand. Nun spüren Sie mit apt-file search libavdevice/avdevice.h schnell das Paket auf, das die fehlende Header-Datei enthält: Es handelt sich um libavdevice-dev. Bis das Kompilieren klappt, steht im Beispiel dieses Katz- und Maus-Spiel auch noch für libavfilter-dev und libqimageblitz-dev an. Dann baut Buildpackage ein funktionierendes Paket für Ffdiaporama 1.5 (Abbildung 2).

Abbildung 2: Lohn der Mühe: Die aktuelle Version 1.5 von Ffdiaporama läuft nun auch unter der LTS-Version Ubuntu 12.04. Die Installation über den Paketmanager hat, anders als make install, dabei das System vor Schaden geschützt, und das Programm lässt sich notfalls wieder rückstandsfrei entfernen.

Entstanden ist das Problem mit den fehlenden Devel-Paketen, weil uupdate die Voraussetzungen für den Paketbau (die Build-Depends) aus Version 1.3 übernommen hat. Ein leistungsfähiges Build-System wie Automake (bekannt von ./configure; make; make install) oder Cmake hätte den Fehler bereits vor dem Kompilieren mit nachvollziehbaren Meldungen wie Could NOT find Paket oder configure: error: Package requirements (Paket >= Version) were not met abgefangen. Doch Ffdiaporama benutzt das einfacher gestrickte Qmake.

Um bei anderen Fehlschlägen, bei denen es nicht um eine fehlende Abhängigkeit geht, aus dem unverständlichen Kauderwelsch im Konsolenfenster schlau zu werden, empfiehlt es sich, nach dem ersten Auftreten des Worts error zu suchen. Da in der Regel auch schon andere Anwender auf das gleiche Problem gestoßen sind, hilft eine Internet-Suche nach der Fehlermeldung oft weiter.

From Scratch

Bisher haben wir uns ganz auf die Helfer-Skripte (Abbildung 3) verlassen, durch die sich das Debian-Build-System auszeichnet: Dpkg-source hat die Quell-Tarballs ausgepackt, Dpkg-buildpackage das Kompilieren und Verpacken in ein Paket automatisiert.

Abbildung 3: Der Debian-Paketierungs-Workflow stützt sich auf die vier Tools Dpkg-source, Dpkg-buildpackage, Uupdate und Dh_make, die den komplizierten Prozess hinter den Kulissen vor dem Anwender verbergen.

Auch für das "Debianisieren" des Quellcodes einer Software, also dem Erzeugen der Steuerdateien im Unterordner debian/, die sowohl das Kompilieren als auch die Paketerzeugung automatisieren, gibt es mit dh_make einen mächtigen Helfer. Wir werden ihn gleich an Ffdiaporama 1.5 ausprobieren – auch wenn wir schon mit Hilfe eines Updates der veralteten Original-Ubuntu-Quellen an die aktuelle Version gekommen sind. Es zeigt, wie der Paketbau ohne Vorlage funktioniert.

Packen Sie dazu zuerst den Upstream-Quellcode aus. Die Dateien sollten sich danach in einem Unterordner mit dem Namen Programm_xx.yy befinden. Der Name darf muss außer Kleinbuchstaben nur noch den Unterstrich zwischen Name und Version enthalten. Aus diesem Verzeichnis – in unserem Fall ffdiaporama_1.5/ – heraus aufgerufen erzeugt der Befehl

$ dh_make -p Name_Version --createorig

einen Steuerordner, auf dessen Basis dpkg_buildpackage oft ohne oder mit nur minimalen Anpassungen erfolgreich durchläuft. dh_make fragt, für welchen Pakettyp es den Debian-Ordner vorbereiten soll. Fast immer ist hier die Option s ("single-binary package") die richtige Wahl, die anderen sind eher ein Fall für erfahrene Maintainer.

Nach dem Aufruf von Dh_make müssen Sie in der Datei control an den mit spitzen Klammern markierten Stellen Beschreibungen für das Paket eintragen. Schreiben Sie nun noch einen kommentierenden Text für die aktuelle Fassung des Pakets in das changelog. Da selbst ein Leerzeichen an der falschen Stelle im changelog den Paketbauprozess zum Scheitern bringt, rufen Sie dazu das Tool dch aus dem Quellordner heraus auf. Es kapselt wie visudo den in der Umgebungsvariablen EDITOR gesetzten Kommandozeileneditor und prüft die Syntax vor dem Speichern. Sowohl Uupdate als auch Dh_make fügen einen Changelog-Standardeintrag ein, den Sie nur zu erweitern brauchen.

Voraussetzungen erfüllt

Haben Sie auf Ihrem System die bereits genannten, für Version 1.5 hinzugekommenen Devel-Pakete installiert, dann läuft Buildpackage nun schon durch. Wie schon beim Update aus Version 1.3 ist ein Binärpaket entstanden, ohne dass Sie sich beim Kompilieren um Details kümmern mussten.

Die vielen Dh-Helper-Skripte bilden zusammen einen mächtigen Autopiloten, der den Quellcode vieler Programme ohne manuelle Anpassung der rules-Datei kompiliert. Dazu ermittelt der Befehl dh auto_configure automatisch, welches Build-System (Autoconfigure, Cmake oder Qmake) ein Programm benutzt, und ruft die passenden Befehle auf. Laut des Entwicklers von Dh_make klappt das bei rund 90 Prozent aller Programme. Das heißt für Sie, dass Sie lediglich Dpkg-source, Dh_make und Dpkg-buildpackage über den Quellcode laufen lassen und einfache Beschreibungen in control eintragen müssen. Dann erhalten Sie automatisch ein Debian-Paket für das ebenfalls automatisch kompilierte Programm.

Das ist eine beeindruckende Leistung – auch wenn die Praxis den Verdacht nahelegt, dass eine Erfolgsquote von 90 Prozent ohne Eingriff per Hand doch ein wenig zu hoch gegriffen ist. Nicht immer gelingt die Paketerstellung im Blindflug. Um bei Fehlern eingreifen zu können, gilt es, den Inhalt eines debian/-Steuerordners und die Funktion der darin enthaltenen Dateien zu kennen. Abbildung 4 zeigt den Inhalt, wie ihn Dh_make automatisch im Upstream-Quellcode von Ffdiaporama erzeugt. Zum Glück sind nur drei der vielen Dateien zwingend für den Paketbau erforderlich: control, rules und changelog. Die übrigen Dateien haben eine Bedeutung für Debian-Policy-konforme Pakete [6], spielen aber beim Bau von Paketen für den Eigengebrauch keine Rolle.

Abbildung 4: Das Tool Dh_make bereitet den Quellcode einer Software für das automatische Kompilieren und Verpacken in ein Paket vor. Der den Paketbau steuernde Ordner debian/ enthält verwirrend viele Template-Dateien (links), doch strikt erforderlich sind zum Glück nur drei davon (rechts).

Ans Eingemachte

Vergleichen wir nun die drei relevanten Dateien im Original-Ffdiaporama-Paket aus dem Ubuntu-Repository mit den von Dh_make erzeugten Versionen. Sie zeigen exemplarisch, wie Sie in die Automatik eingreifen, selbst wenn nicht alle der sichtbaren Änderungen für einen erfolgreichen Buildpackage-Durchlauf erforderlich sind.

Die Datei control ist eine Textdatei mit beschreibenden Daten. Abbildung 5 bildet links das von Dh_make erstellte Template ab, rechts die ausgefüllte Fassung aus dem Ubuntu-Paket von Launchpad. Die Kurzbeschreibung (erste Zeile nach Description:) und die folgende mehrzeilige Beschreibung lassen sich leicht mit Text von der Programm-Webseite ausfüllen. Hinzugekommen sind auch noch die Upstream-URL, sowie – Debian-spezifisch – ein Uploader und das Git-Repository der Ubuntu-Paketentwickler. Ihre Pakete für den Hausgebrauch benötigen diese Felder nicht: Hier genügt es, nur den Text zwischen spitzen Klammern in der linken Fassung zu ersetzen.

Abbildung 5: Die Datei control enthält beschreibende Daten für den Paketbauprozess und das spätere Binärpaket.

Für Depends: enthält die automatisch erzeugte Fassung von control lediglich die Variablen ${shlibs:Depends} und ${misc:Depends}, die der automatische Bauvorgang mit automatisch errechneten Abhängigkeiten ausfüllt. Dabei finden sich alle Shared Libraries, gegen welche die im Paket enthaltenen Binaries verlinken, nicht jedoch im Hintergrund aufgerufene eigenständige Programme. Ffdiaporama ruft Ffmpeg auf und benötigt daher das Paket ffmpeg als (ausnahmsweise manuell) eingetragene Abhängigkeit.

Für eigene Pakete sind die Einträge unter Build-Depends entbehrlich: Sie sind für Paketquellen gedacht, die auf den Servern der Distributoren in einer minimalen Umgebung gebaut werden sollen. Bringt Ihr System jedoch schon alle Pakete mit, die zum Kompilieren nötig sind, dann funktioniert der Buildpackage-Durchlauf auch mit leeren Build-Depends. Auf das Binär-Paket haben die Bauabhängigkeiten keinen Einfluss, solange der Bauprozess durchläuft.

Ausgegraut rechts unten in Abbildung 5 findet sich eine zweite Package:-Definition: Die Ubuntu-Entwickler haben Ffdiaporama in zwei Pakete aufgeteilt, ffdiaporama und ffdiaporama-data. Damit das funktioniert, braucht Dpkg-buildpackage Dateien mit den Namen ffdiaporama.install und ffdiaporama-data.install, die Listen der zu den Teilpaketen gehörigen Dateien enthalten. Damit trennen die Distributoren für die 32- und 64-Bit-Systeme gesondert zu installierende Dateien von den für alle Plattformen gleichbleibenden Daten.

Das gehört aber schon zur hohen Schule der Paketbaukunst. Fehlen die Zeilen ab Package: ffdiaporama-data und auch die .install-Dateien, dann entsteht ein einziges ffdiaporama-Paket, das alle zum Programm gehörigen Dateien enthält. Es funktioniert auf der Architektur, auf der es gebaut wurde, einwandfrei. Dann braucht das Debian-Build-System also – anders als RPM – keine Dateiliste für den Paketinhalt. Es packt einfach alle von make install eingespielten Dateien ein.

Steuerzentrale

Während control lediglich beschreibende Daten enthält, zieht rules während des ganzen Buildpackage-Durchlaufs die Strippen. Das schließt auch das Kompilieren des Quellcodes ein. Bei rules handelt es sich um ein Makefile, wie es auch beim Übersetzen von Programmen zum Einsatz kommt. Abbildung 6 zeigt links die von Dh_make automatisch erzeugte Version, rechts die Fassung aus dem Ubuntu-Ffdiaporama-Paket. Bleiben wir zuerst bei der Default-Variante: Abzüglich der Kommentare besteht sie aus den ebenso kurzen wie kryptischen Zeilen:

%:
   dh $@

Um sie zu verstehen, muss man ein paar Grundlagen des Makroprozessors GNU Make kennen. In Makefiles steht Name: für ein sogenanntes Target. So führt make install zum Beispiel alle Shell-Befehle aus, die im Makefile auf install: folgen. Bei %: handelt es sich um ein Wildcard-Target, das Make immer ausführt, egal ob Sie es mit make Leberwurst oder make Sauerkraut aufrufen.

Abbildung 6: Die Datei rules im Unterordner debian/ ist das zentrale Makefile, das den ganzen Paketbauprozess steuert.

Die Variable $@ enthält in Makefiles stets den Namen des aufgerufenen Targets. Daher ruft make -f rules dh_auto_configure über Bande dh dh_auto_configure auf. Da es sich bei rules um eine ausführbare Datei handelt und die erste Shebang-Zeile Make als Interpreter wählt, funktioniert auch der direkte Aufruf rules dh_auto_configure.

Über den Umweg dieses Makefiles, das den Target-Namen als Parameter an dh weiterreicht, ruft Dpkg-buildpackage zunächst dh clean, dh build und fakeroot dh binary auf. Diese drei Aufrufe entsprechen den drei Hauptphasen des Paketbaus: Reinigen des Quellcode-Verzeichnis von eventuell vorausgegangenen Bauversuchen, Kompilieren des Quellcodes (./configure und make) sowie Verpacken der kompilierten Dateien in ein Debian-Paket.

Alle drei Dh-Aufrufe starten (wiederum mittels des Makefiles) weitere Helfer, die die eigentliche Arbeit verrichten. Schon ihre Zahl spricht für Debian-typische Gründlichkeit: Drei Skripte beseitigen Reste eines etwaigen früheren Compiler-Durchlaufs, vier übernehmen das Konfigurieren und Kompilieren des Quellcodes (./configure und make oder Entsprechung), ganze 42 zeichnen für den make install-Aufruf und das Erzeugen des Debian-Pakets verantwortlich (Abbildung 7).

Abbildung 7: Dh_buildpackage ruft, durch das Makefile rules vermittelt, zunächst dh clean, dh build und fakeroot dh_binary auf. Diese starten eine Vielzahl von Helfer-Skripten, die den Quellcode kompilieren und das Debian-Paket bauen.

Ein Detail am Rande: dh binary und seine untergeordneten Helfer laufen unter der Ägide von Fakeroot. Innerhalb der Fakeroot-Umgebung dürfen sie Dateien schreiben, deren Besitzer root ist, ohne jedoch "echte" Root-Schreibrechte zu besitzen. Das ist nötig, weil systemweit zu installierende Dateien aus Sicherheitsgründen praktisch immer root gehören. Fakeroot verhindert aber trotzdem, dass ein aus dem Ruder laufender Aufruf von make install das System beschädigt.

Über Bande

Welchen Sinn der indirekte Aufruf von dh Parameter via Makefile ergibt, zeigt ein Blick auf die rechte Variante von rules aus dem Original-Ffdiaporama-Paket in Abbildung 7. Die rot markierten, mit override_ beginnenden Targets demonstrieren, wie sich dh_xxx-Aufrufe durch eigene Shell-Befehle ersetzen lassen: Jedes override_-Target signalisiert dem Build-System: Führe mich statt des Targets dh_xxx aus.

Das originale Ubuntu-Rules-File ersetzt dh_auto_configure durch den Befehl qmake-qt4 ffDiaporama.pro, der Qmake-spezifischen Entsprechung für das geläufige ./configure. Das mag den Maintainern sicherer erscheinen, als auf die Automatik zu vertrauen. Doch auch die von dh_make automatisch erzeugt Variante funktioniert: Das Helper-Skript erkennt Qmake als Build-System offenbar korrekt. Es gibt in der Praxis aber auch Fälle, in denen nur das Ersetzen der Debian-Helper durch eigene Shell-Befehle zum Erfolg führt.

Der Override dh_fixperms kombiniert dagegen Konsolenbefehle mit dem Debian-Helper, statt ihn komplett zu ersetzen – ein in der Praxis häufiges Vorgehen. Im konkreten Fall geht es darum, vor dem Aufruf von dh_fixperms, einem automatisieren Check auf Sicherheitslücken in den Dateirechten, noch einige Schreibrechte per Hand zu setzen. Der dritte Override ersetzt dh_install nicht, sondern gibt dem Helper-Skript lediglich einen Aufrufparameter mit. Welche davon die Debian-Helper verstehen, sowie ihre Aufgabe innerhalb des Paketbauprozesses, beschreiben die Manpages der Skripte [7].

Ein wichtiger Tipp für die Praxis: Ruft zum Beispiel dh_auto_configure den richtigen Configure-Befehl auf, Sie wollen diesem aber noch einen Parameter mitgeben, dann schreiben Sie ein override_dh_auto_configure:-Target mit dem Inhalt dh_auto_configure -- --Parameter. Alle Parameter nach dem -- gibt das Helper-Skript unverändert an den von ihm aufgerufenen Befehl weiter.

Vom Gesellen zum Meister

Nun kennen Sie die Grundlagen der Debian-Paketerstellung. Das reicht aus, um für viele Anwendungen eigene Pakete zu bauen. Bei Problemfällen hilft der Debian-Guide für Paket-Maintainer [8] weiter, insbesondere die Kapitel 2.4 bis 2.9, 4, 6 und 9.

Wenn der Autopilot scheitert, dann müssen Sie zunächst herausfinden, wie sich ein Programm auf der Konsole kompilieren lässt. Dann setzen Sie diese Erkenntnisse in Override-Targets auto_configure, auto_make, eventuell auch auto_install in rules um. Alle Feinheiten des Debian-Build-Systems zu meistern, gleicht vom Umfang her allerdings ein wenig der Erbauung Roms: An einem Tag erreicht dieses Ziel niemand.

Angesichts der verwirrenden Vielzahl der Helfer-Skripte sollten Sie aber nicht vergessen, dass es bei den prall gefüllten Debian-Repositories ohnehin selten nötig ist, ein Paket ganz ohne Vorleistung zu erstellen. Das Update der Debian-Quellen auf eine neue Programmversion geht insbesondere bei Minor-Versionssprüngen oft reibungslos über die Bühne – und dauert dann kaum länger als ein Viertelstündchen. 

Glossar

Shebang

Die Zeichenfolge #! (engl. Jargon # "sharp" oder "hash", ! "bang"). Die auf den Shebang folgende Angabe (etwa #!/bin/sh) verweist auf den Interpreter für den Code in dieser Datei. Dieser Mechanismus existiert ausschließlich bei unixoiden Betriebssystemen

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 8 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

LinuxCommunity kaufen

Einzelne Ausgabe
 
Abonnements
 

Ähnliche Artikel

Kommentare