Ihr Lieblingsprogramm gibt es nur als Quelltext zum Selberbauen? Kein Problem: Mit Checkinstall bekommen Sie die Software sauber ins System und auch wieder heraus.
Linux-Anwender sehen sich heute selten mit der Situation konfrontiert, Software aus Quellcode übersetzen und installieren zu müssen. Die Paketquellen aller wichtigen Distributionen zeigen sich bestens bestückt, bei Debian “Squeeze” finden sich beispielsweise über 29?000 Pakete in den Repositories [1]. Hinzu kommen zahlreiche Spezialquellen mit launigen Namen wie Launchpad, Packman, RPM Fusion, Medibuntu oder Demudi, die weitere Pakete anbieten.
Manchmal kommt es trotzdem vor, dass Sie auf der Suche nach einem Programm auf Freecode [2] oder Sourceforge [3] nur auf den Quellcode stoßen. Dann heißt es selbst Hand anlegen. Gleiches gilt, wenn Sie auf die neuste Entwicklerversion angewiesen sind und diese direkt aus dem Versionskontrollsystem ausbuchen.
Licht und Schatten
Zwar erweist sich der Zugriff auf den Quellcode zweifelsohne als Vorteil von Linux gegenüber proprietären Plattformen, der Einsatz von Sourcen bringt aber – vom Aufwand des Übersetzens einmal ganz abgesehen – auch Probleme mit sich. Schließlich haben die Entwickler nicht umsonst das Paketmanagement erfunden und pflegen ihre Ansätze mit meist großen Aufwand.
Wer Software mit dem Compiler übersetzt und mit make install ins System integriert, der mogelt sich an den Paketmanagementsystemen vorbei. Diese bemerken solche Software schlicht nicht und berücksichtigen sie folglich nicht beim Prüfen von Abhängigkeiten. Dabei geht zwangsläufig irgendwann der Überblick über die installierte Software verloren. Zudem lässt sich auf diese Weise installierte Software nur mit Mühe wieder entfernen, weil viele Entwickler dem Makefile das dazu erforderliche Ziel uninstall nicht beifügen.
Das Aktualisieren einer direkt aus den Quellen eingerichteten Software fällt ebenfalls kompliziert aus. Weitere Probleme drohen bei selbst übersetzten Bibliotheken: Installieren Sie ein anderes Programm, das die selbe Bibliothek benötigt, ganz regulär mit Hilfe des Paketmanagements, bemerkt dies das Vorhandensein der Bibliothek nicht und behandelt sie als fehlende Abhängigkeit.
Gern führen Verfechter des manuellen Paketbaus das Argument des komfortablen Verteilens an, was für den Einsatz des im folgenden vorgestellten Tools Checkinstall [4] aber nicht zutrifft: Das Tool schafft Probleme mit Abhängigkeiten nicht oder nur bedingt aus der Welt.
Wer also den Bau von Paketen anstrebt, um Software für bestimmte Distributionen zu verteilen, dem bleibt kaum eine Alternative zu manuellen Verfahren wie Dpkg-deb (Debian/Ubuntu) oder Rpmbuild (Fedora/OpenSuse). Das bedeutet aber einen erheblichen Aufwand und setzt grundlegende Kenntnisse im Paketbau sowie im Umgang mit Entwicklungswerkzeugen voraus.
Funktionsumfang
Möchten Sie dagegen auf einem lokalen Rechner Software über das Paketmanagement verwalten, eignet sich die automatische Methode mit Checkinstall optimal – und genau dafür ist sie gedacht. Das pfiffige kleine Skript von Felipe Eduardo Sánchez Díaz Durán kursiert seit vielen Jahren – erste Versionen stammen aus dem Jahr 2000.
Checkinstall erstellt aus einem vorkompilierten Quelltextpaket automatisch ein Distributionspaket. Das funktioniert via Parameter wahlweise für Debian, OpenSuse oder sogar Slackware. In Abhängigkeit des zugehörigen Parameters spuckt es am Ende ein passendes Paket aus. Die über Jahre am häufigsten eingesetzte Checkinstall-Version 1.6.1 datiert auf 2006, die noch aktuelle und in nahezu allen Distributionen enthaltene Version 1.6.2 immerhin auf das Jahr 2008.
Gemäß Beschreibung in den Debian Paketquellen handelt es sich bei dem Programm um einen “Installations-Verfolger”, was ziemlich treffend beschreibt, was das Skript tut: Checkinstall überwacht die Anpassungen von Installationsroutinen wie make install und erstellt aus den gesammelten Daten ein Paket. Sie können das erstellte Paket dann nutzen, um die Software bei Bedarf wieder vom System zu entfernen, theoretisch aber auch, um sie auf anderen Rechnern zu installieren.
Letzteres funktioniert nur bedingt, je nachdem ob das Programm Abhängigkeiten aufweist und welcher Art diese sind. Außerdem gibt es weitere Einschränkungen: Das Skript funktioniert nicht bei Programmen, die statisch gegen die Libc linken, oder bei solchen, bei denen das SUID/GUID-Bit gesetzt ist.
Checkinstall erledigt seine Aufgabe arbeitsteilig: Nach dem Sammeln der Informationen erstellt es ein weiteres, temporäres Skript und führt dieses wiederum mit dem Skript installwatch aus, das ebenfalls zum Umfang von Checkinstall gehört. Dieses wiederum greift auf eine Bibliothek zurück, die letztendlich die Dateizugriffe protokolliert.
Einsatz
Haben Sie den Quellcode des auserkorenen Programms heruntergeladen, in einem beliebigen mit passenden Rechten versehenen Verzeichnis entpackt und die Entwicklungswerkzeuge installiert, dann wäre beim regulären Vorgehen zum Übersetzen von Quellcode der klassische Dreisatz der nächste logische Schritt:
# ./configure && make && make install
Dabei prüft der Configure-Aufruf Abhängigkeiten und Voraussetzungen, das Kommando make zeichnet für das eigentliche Übersetzen zuständig und make install kopiert die übersetzten Code-Teile schließlich im System, was bedeutet, dass es je nach Komplexität des Programms zahlreiche Files im Dateibaum verteilt.
Um das Ausführen eines mitgelieferten Configure-Skriptes kommen Sie nicht herum. Nur so finden Sie heraus, ob die Voraussetzungen für die Installation überhaupt erfüllt sind, und haben die Möglichkeit vorab nachzubessern – etwa indem Sie zugehörige Devel-Pakete, Compiler und Bibliotheken installieren (Abbildung 1).
Den Aufruf make install sollten Sie dagegen künftig durch checkinstall ersetzen. Ohne Parameter führt Checkinstall ein make install aus. Alternativ geben Sie das zu beobachtende Skript über einen Parameter an:
# checkinstall -D install.sh
Um das Auflösen von Abhängigkeiten müssen Sie sich allerdings wie zuvor selbst kümmern. Es besteht die Möglichkeit, Abhängigkeiten mit --requires direkt anzugeben. Damit findet sich die Angabe aber nur in der Steuerdatei des Pakets wieder. Die Option -D im Beispiel sorgt für das Erzeugen eines Debian-Paketes, weitere wichtige Schalter entnehmen Sie der Tabelle “Optionen”.
Optionen
| Option | Funktion |
|---|---|
-D |
erzeugt ein Debian-Paket |
-R |
erzeugt ein RPM-Paket |
-S |
erzeugt ein Slackware-Paket |
--include= |
Dateien beim Bauen des Pakets miteinbeziehen |
--exclude= |
Dateien nicht mit ins Paket aufnehmen |
--nodoc |
keine Dokumentation mit ins Paket aufnehmen |
--newslack |
erzeugt eine Paketbeschreibung für Slackware 8.1 oder neuer |
--backup |
Dateien sichern, die das Installationsskript verändert |
--help |
zeigt eine Übersicht über alle Optionen |
--version |
zeigt die Programmversion an |
Bei Bedarf unterbinden Sie das automatische Einrichten mit dem Parameter --install=no und erzeugen nur das Paket, etwa zum späteren Installieren in einem Live-System. Hat das Skript alle gewünschten Parameter erfasst, stellt es abschließend einige Fragen.

Abbildung 2: Checkinstall fragt interaktiv fehlende Informationen ab, etwa eine Beschreibung für das Paket.
Das Programm bietet an, die Dokumentation ins Paket aufzunehmen. Danach haben Sie die Möglichkeit, eine Beschreibung für die Software zu hinterlegen. Diese findet sich später im Paketmanager wieder. Wer Checkinstall nur nutzt, um ein Quellpaket für seinen lokalen Rechner zu installieren, verzichtet darauf in der Regel.
Danach zeigt Checkinstall eine Übersicht der Informationen an, die Sie noch einmal bearbeiten dürfen. Achten Sie in jedem Fall auf den korrekten Namen des Pakets nebst Versionsnummer. Checkinstall konstruiert diese beiden Informationen ohne Angabe aus dem Namen des Verzeichnisses, in dem Sie das Skript ausführen.
Der richtige Paketname ist besonders wichtig, wenn Sie eine neuere Version eines Paketes installieren, das Sie in einer älteren Version oder aus einer anderen Quelle über das reguläre Paketmanagement bereits installiert haben. Mit der Möglichkeit, den Namen dann entsprechend abzuändern, verhindern Sie, dass das System ein existentes Paket überschreibt.
Checkinstall warnt aber im Übrigen davor, dass ein Überschreiben einer über das reguläre Paketmanagement bereits installierten Datei droht, und bricht dann ab. In ähnlicher Weise führt eine falsche Versionsnummer dazu, dass die Paketverwaltung das ältere Paket wieder als Aktualisierung vorschlägt. Sie kommen also in solchen Fällen nicht umhin, sich mit dem Schema der Programmversionen der von Ihnen genutzten Distribution auseinanderzusetzen. Checkinstall zeigt nach dem Fertigstellen der Installation an, ob diese erfolgreich verlief.
Fazit
Wann immer Sie in Zukunft Software aus Quellen übersetzen wollen oder müssen, lohnt sich der Einsatz von Checkinstall. Das pfiffige Skript protokolliert den Installationsprozess und stellt damit bei Bedarf eine Option zur Deinstallation bereit – quasi als Nebeneffekt des erstellten Pakets.
Checkinstall erweist sich auf jeden Fall als sehr nützlich. Das Tool aber deshalb als Paketbau-Automaten zu beschreiben, wäre reichlich übertrieben, denn die Checkinstall-Methode ist und bleibt schnell und schmutzig. Sie erstellen lediglich ein einfaches Paket, in der Regel ohne jede Information zu Abhängigkeiten. Daher eignen sich mit dem Skript gebaute Pakete nicht zur Weitergabe – es sei denn, Sie berücksichtigen Abhängigkeiten bereits beim Bauen.
Infos
[1] Anzahl der Pakete in “Squeeze”: http://de.wikipedia.org/wiki/Debian#Versionsgeschichte
[2] Freecode: http://freecode.com
[3] Sourceforge: http://sourceforge.net
[4] Checkinstall: http://asic-linux.com.mx/~izto/checkinstall/






