Wer unter Linux viel aktuelle Software ausprobiert, kennt das Problem: Neueste Programmversionen existieren oft nur als tar-Archiv und lassen sich lediglich unter Klimmzügen wieder deinstallieren. Checkinstall schafft Abhilfe.

Den Dreisatz ./configure; make; make install kennt wohl jeder, der schon ein Programm aus seiner Quelltext-Form installiert hat. Nur wenige Quellpakete unterstützen aber die saubere Deinstallation der mit make install ins Dateisystem kopierten Dateien [3]. Hier setzt checkinstall von Felipe Eduardo Sanchez Diaz Duran an.

Unter Verwendung der installwatch–Bibliothek überwacht das Programm alle Schreibaktionen, die bei make install oder einem entsprechenden Installationskommando getätigt werden, und merkt sich so eine Liste der neuen Dateien und Verzeichnisse.

Henne oder Ei?

Wenn Sie den GNU-C-Compiler bei der Hand und das fürs Kompilieren nötige Development-Paket glibc-dev (je nach Distribution kann es leicht verändert heißen) installiert haben, brauchen Sie nur noch eine virtuelle Reise nach Mexiko zu unternehmen, um sich von http://asic-linux.com.mx/~izto/checkinstall/ die Quellen für checkinstall zu besorgen.

Es klingt etwas verrückt, aber zur Installation von checkinstall benötigen Sie checkinstall. Natürlich gibt es einen Trick dabei: Das Programm wird zunächst mit dem üblichen Kommando make install installiert. Danach steht das neue Kommando checkinstall zur Verfügung, mit dem Sie die Installation wiederholen:

tar xzf checkinstall-1.5.1.tgz
cd checkinstall-1.5.1
make
su  (root-Passwort eingeben)
make install
checkinstall
exit

Bevor das neue Tool als Paket installiert wird, will checkinstall ein paar Informationen darüber haben, welcher Paketmanager auf dem System normalerweise eingesetzt wird. Auf dem System in Abbildung 1 kommt Debian GNU/Linux zum Einsatz, so dass sich dort die Auswahl d anbietet. Im nachfolgenden Menü zeigt checkinstall diverse Informationsfelder zum Paket, die meist mit sinnvollen Werten gefüllt sind. Über die entsprechende Ziffer ändern Sie den Inhalt eines Feldes.

Abbildung 1: Auswahl des Pakettyps

Abschließend teilt checkinstall Ihnen mit, wie Sie das soeben installierte Paket wieder loswerden können. Im Beispiel lautet das Kommando dpkg -r checkinstall.

Trickserei

Allerdings haben wir checkinstall nicht installiert, um es sofort wieder zu entfernen. Diese Behandlung soll das Programm eher zukünftigen Softwarepaketen zukommen lassen, die sich als noch zu instabil oder zuwenig benutzbar herausstellen. Aber wie arbeitet checkinstall überhaupt?

Die Bibliothek installwatch ersetzt alle Dateifunktionen der Standard-C-Bibliothek durch eigene. Checkinstall benutzt nun den Preload-Mechanismus, um den Funktionen aus installwatch Vorrang vor den “echten” Funktionen zu geben. Die vorgeschalteten Funktionen protokollieren alle Schreibvorgänge und übergeben die so gewonnene Dateiliste an checkinstall. Dieses setzt wiederum den ausgewählten Paketmanager ein, um aus der Liste ein Slackware-, Red Hat- oder Debian-Paket zu erzeugen. Zum Schluss wird das frisch gebaute Paket mit dem distributionseigenen Paketmanager installiert.

Rote Hüte backen

Als praktisches Beispiel darf die Installation des in einer früheren “out of the box”-Ausgabe [1] vorgestellten Fraktalgenerators XaoS[2] herhalten. Ist dessen Quelltext einmal mit tar -xzvf xaos-3.0.tar.gz entpackt, fallen folgende Schritte an:

cd XaoS-3.0
./configure
make
su  (root-Passwort eingeben)
checkinstall

Nach den üblichen Schritten ./configure und make ruft man anstatt make install das Kommando checkinstall auf. Auf die Frage nach dem Pakettyp wählen Benutzer RPM-basierter Distributionen r aus, ändern mit 6 die Gruppe auf Applications/Graphics und fügen mit 1 eine Kurzbeschreibung, beispielsweise realtime fractal zooming for X and console, hinzu.

Abbildung 2: Installation als RPM-Paket

Nach abgeschlossener Installation informiert Sie checkinstall wie schon im ersten Beispiel, welches Kommando für die Deinstallation zuständig ist, in diesem Fall also rpm -e XaoS-3.0-1 (Abbildung 2). Ferner legt das Programm das erzeugte rpm-Paket für spätere Installationen im Verzeichnis /usr/src/rpm/RPMS/i386 ab. So ist es nach dem Entfernen jederzeit möglich, das Paket mit rpm -i XaoS-3.0-1.i386.rpm neu einzuspielen. Ähnliches gilt auch für Debian-Pakete, nur werden sie nicht in der /usr/src-Hierarchie, sondern im aktuellen Quellverzeichnis abgelegt.

Abbildung 3: rpm zeigt das installierte Paket an

Abbildung 3 zeigt die zur Kontrolle abgefragte RPM-Datenbank. Mit rpm -qi XaoS (die Versionsnummer darf bei installierten Paketen fehlen) zeigt der Paketmanager die von uns festgelegten bzw. automatisch generierten Informationen zum XaoS-Paket an.

Standards und Spezielles

Normalerweise hantiert man in einem Linux-System nur mit einem Paketformat. Da wird das permanente Erfragen des Pakettyps durch checkinstall schnell lästig. Doch zum Glück benutzt das Programm eine Datei mit Standardeinstellungen, die Sie nach Belieben anpassen dürfen. Dieses Konfigurationsfile finden Sie unter /usr/local/lib/checkinstall/checkinstallrc. Es ist gut kommentiert und erlaubt neben der Auswahl des Pakettyps (INSTYPE) auch, ein Verzeichnis zum Speichern der erzeugten Pakete (PAK_DIR) oder zusätzliche Optionen für die verschiedenen Paketmanager (RPM_FLAGS, DPKG_FLAGS) festzulegen.

Checkinstall versteht zudem eine Reihe von Kommandozeilenoptionen beim Aufruf. Als sehr nützlich erweist sich -si. Diese Option erlaubt es, auch interaktive Mechanismen, die während der Installation noch Benutzereingaben erfordern, zu überwachen. Die komplette Dokumentation zu checkinstall finden Sie übrigens unter /usr/doc/checkinstall-1.5.1/README.

Bei vielen Distributionen gehört es zum guten Ton, dass Dokumentation zu einem Paket in /usr/doc/Paketname installiert wird. Checkinstall versucht sich daran zu halten und sucht beim Aufruf im Quellverzeichnis das Verzeichnis doc-pak. Existiert es, wird sein Inhalt beim checkinstall-Lauf nach /usr/doc/Paketname kopiert – und selbstverständlich bei der Deinstallation mit entfernt.

Limits

Natürlich hat jedes Tool seine Grenzen. So kann checkinstall die Dateizugriffe eines statisch gelinkten Installationsprogramms nicht überwachen, weil hier der Preload-Mechanismus nicht funktioniert. Die gleiche Beschränkung gilt für Programme, die nach dem Start mit den Rechten eines anderen Benutzers laufen. Solchen Programmen ist der Preload aus Sicherheitsgründen verboten.

Für die Zukunft plant der Autor eine bessere Menüführung durch Dialogboxen, eine Manpage zum schnellen Nachschlagen der Optionen und die kryptographische Signierung der erzeugten Pakete. Es gibt also viel zu erwarten von einer kommenden Version 2.0.