Beim Bau von Softwarepaketen für eine bestimmte Distribution führen viele Wege zum Ziel. Checkinstall bietet vermutlich den einfachsten Weg, um selbst kompilierte Software mit der Paketverwaltung zu versöhnen.

Von Zeit zu Zeit kommt man als Linux-Anwender in die Verlegenheit, ein Paket aus dem Quellcode selbst kompilieren zu müssen. Die Gründe dafür sind unterschiedlich: Mal fehlt trotz Unmengen von Software in den Archiven der Distributionen das Gewünschte, mal wurde im Paket aus dem Repository eine benötigte Funktion nicht einkompiliert, mal hinkt die Version aus den Paketquellen um mehrere Nummern hinter der aktuellen Entwicklung her.

In diesen Fällen kommt üblicherweise der bekannte Dreisatz aus ./configure; make; make install zum Bauen des Programms aus dem Quellcode zum Zug; mit ein wenig Erfahrung lässt sich so gut wie jedes Programm aus dem Quellcode kompilieren. Allerdings umgehen Sie dabei das Paketmanagement des Systems: Der letzte Schritt des Dreisatzes installiert die fertig erstellte Software glatt daran vorbei.

Daraus resultieren gleich mehrere Nachteile: Bietet die Distribution im Lauf der Zeit eine neuere Version an, bleiben Sie als Anwender auf dem nun veralteten Eigenkompilat sitzen. Die Paketverwaltung meldet das Update nicht, Sie müssen die Software erneut selbst übersetzen. Möchten Sie die manuell installierte Software wieder entfernen, müssen Sie darauf hoffen, dass der Autor des Programms eine Uninstall-Funktion als Ziel in seiner Make-Datei verankert hat. Andernfalls gilt es, selbst Hand anzulegen und die Anwendung manuell zu entfernen.

Noch schlimmer wiegt die Situation bei selbst erstellten Bibliotheken. Installieren Sie Anwendungen, die auf solche einer händisch installierten Bibliothek aufsetzen, erkennt die Paketverwaltung die bereits erfüllte Abhängigkeit nicht. Am Ende existieren mehrere Versionen der Bibliothek auf dem System, es drohen Inkonsistenzen in der Paketverwaltung und instabile Software.

Sauber installieren

Abhilfe bietet hier das Kommandozeilenprogramm Checkinstall [1]. Es ersetzt den letzten Schritt im Linux-Dreisatz und erstellt ein rudimentäres Paket, das sich über die Paketverwaltung installieren und somit auch wieder sauber deinstallieren lässt (Abbildung 1). Die mit Checkinstall erstellten Pakete erfüllen in der Regel ihren Zweck, unterscheiden sich jedoch in einigen Punkten von einem offiziell für die Distribution oder zur Veröffentlichung im Internet erstellten Paket. Sie sollten daher mit Checkinstall nur auf dem eigenen Systemen arbeiten und die auf diesem Weg gebauten Pakete nicht im Netz verteilen.

Abbildung 1: Checkinstall hilft beim Verschnüren einer aus dem Quellcode gebauten Anwendung zu einem über die Paketverwaltung des System installierbaren Paket.

Checkinstall kann DEB-, RPM- und TGZ-Pakete erstellen. Die Vorgehensweise des Programms unterscheidet sich hauptsächlich in einem wesentlichen Punkt vom bekannten Dreisatz: Es führt zwar nach seinem Aufruf intern make install aus, protokolliert allerdings nur mittels des in Checkinstall eingebundenen Werkzeugs installwatch [2] die geänderten oder neu erstellten Ordner und Dateien, ohne dass es diese Daten im Dateisystem ablegt. Abschließend schnürt Checkinstall aus den Daten ein einfaches Paket, das sich dann mit den jeweiligen Werkzeugen der Distribution sauber installieren lässt.

“Hallo Welt” im Eigenbau

Als Beispiel zum Bauen eines Programms aus dem Quellcode und der Installation mit Checkinstall dient im Folgenden ein Debian/Ubuntu-System und das Demo-Programm Hello [3], das der GNU-Variante eines “Hello World” entspricht. Für die Installation müssen Sie zunächst das Paket checkinstall mitsamt den wichtigsten Build-Werkzeugen build-essential aus der Paketverwaltung installieren. Anschließend laden Sie den Quellcode von Hello aus dem Netz [4] und entpacken das Archiv hello_2.10.orig.tar.gz in einem temporären Verzeichnis.

Im nach dem Entpacken neu entstandenen Verzeichnis hello-2.10 führen Sie die ersten zwei Schritte des Dreisatzes ./configure und make aus. Bei Hello läuft das Configure-Skript ohne Probleme durch, bei größeren Anwendungen jedoch fehlen üblicherweise die benötigten Entwicklerpakete, sodass das Skript mit einer Fehlermeldung abbricht. Diese müssen Sie aufmerksam studieren und herauslesen, was zum Bauen fehlt (siehe Kasten “Abhängigkeiten”). Laufen einmal beide Schritte ohne Fehler durch, schnüren Sie anschließend mittels sudo checkinstall den Code zu einem Paket – in der Regel benötigt dieser Aufruf administrative Rechte.

Vorgaben anpassen

Nach dem Programmstart erfolgt als Erstes eine Abfrage, ob Sie eine Paketdokumentation anlegen möchten. Das sollten Sie bejahen, denn so schreibt Checkinstall (sofern im Quellcode vorgesehen) die entsprechenden Dateien nach /usr/share/doc. Danach stellt Checkinstall Ihnen eine Reihe weiterer Fragen in Form einer nummerierten Liste (Listing 1).

$ sudo checkinstall
checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran
  Diese Software wurde unter der GNU GPL veröffentlicht
*****************************************
**** Debian package creation selected ***
*****************************************
Das Paket wird entsprechend dieser Vorgaben erstellt:
0 -  Maintainer: [ root@test-VirtualBox ]
1 -  Summary: [ Package created with checkinstall 1.6.2 ]
2 -  Name:    [ hello ]
3 -  Version: [ 2.10 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ checkinstall ]
7 -  Architecture: [ amd64 ]
8 -  Source location: [ hello-2.10 ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ hello ]
12 - Conflicts: [  ]
13 - Replaces: [  ]
Geben Sie die betreffende Nummer ein, um die Vorgaben zu ändern:

Aus dem Quellcode und dem Ordnernamen zieht es dabei schon eine Reihe von wichtigen Informationen und fügt diese automatisch als Vorgabe an. So fischt Checkinstall zum Beispiel den Namen des Programms und die Versionsnummer aus dem Namen des aktuellen Ordners, bei Hello also aus hello-2.10. Fehlt dem Programmordner die Versionsnummer, dann benennen Sie den Ordner vor dem Ausführen von Checkinstall einfach um.

Sie ändern die von Checkinstall gemachten Vorgaben, indem Sie die entsprechende Zahl eintippen, den Änderungswunsch eingeben und danach die Eingabetaste betätigen. Welche Änderungen hier sinnvoll sind, hängt zum Teil von der Art und Komplexität des zu erstellenden Programms ab. Immer sinnvoll erscheint die Angabe einer Paketbeschreibung sowie des eigenen Namens und einer E-Mail-Adresse. Unter 6 – Gruppe trägt Checkinstall als Standard immer checkinstall ein. Bei Bedarf passen Sie das an die Gegebenheiten der Distribution an; im Fall von Debian und Hello wäre das zum Beispiel die Gruppe Devel.

Genauso wichtig ist die Angabe einer mit dem Vorgehen der jeweiligen Distribution korrespondierenden Versionierung. Debian “Stable” führt das Hello-Paket in der Version 2.9-2+deb8u1 in seinen Quellen. Bei Debian “Unstable” (oder “Sid”) liegt das Paket hingegen bereits in der Version 2.10-1 vor. Weisen Sie Checkinstall nun an, dem selbst erstellten Paket die Versionsnummer 2.10-1 zu geben, dann trägt das Paket am Ende die Versionsnummer 2.10-1-1, also mit einer zusätzlichen -1 am Ende. Somit trägt die selbst gebaute Version selbst im Vergleich zu Debian “Unstable” eine höhere Versionsnummer und ist vor Updates durch die Paketverwaltung geschützt.

Die Punkte 10 – Requires, 12 – Conflicts und 13 – Replaces, die Abhängigkeiten und Konflikte betreffen, bedürfen nun etwas mehr Aufmerksamkeit. Existiert bereits ein Paket oder ein an eine Distribution angepasster Quellcode dieser Software, so bietet sich jetzt die Gelegenheit, die Abhängigkeiten und Konflikte abzukupfern. Angaben dazu finden Sie in der Datei control im Debian-Verzeichnis des debianisierten Quellcodes oder des schon bestehenden Pakets.

[...]
Installing with make install...
====================== Installations-Ergebnisse ======================
Makefile:20: ../include/biuilddefs: Datei oder Verzeichnis nicht gefunden
make: *** No rule to make target '../include/builddefs'. Schluss
**** Installation fehlgeschlagen. Breche Paket-Erzeugung ab.
Räume auf...OK
Auf Wiedersehen!

Im Fall des sehr einfachen Hello-World-Beispiels war alles korrekt, es gibt keinen Grund zum Eingreifen (Listing 3). Nach Abschluss aller Änderungen führt ein weiterer Druck auf die Eingabetaste zum Bau des Pakets, das anschließend gleich automatisch per dpkg -i auf dem System installiert wird (Listing 4). Zudem liegt die DEB-Datei für Installationen auf anderen Rechnern im Build-Verzeichnis, was einen weiteren Vorteil gegenüber einem make install darstellt.

[...]
Das Paket wird entsprechend dieser Vorgaben erstellt:
0 -  Maintainer: [ Ferdinand Thommes <foo@bar.net> ]
1 -  Summary: [ Hello World mit Checkinstall 1.6.2 paketiert ]
2 -  Name:    [ hello ]
3 -  Version: [ 2.10-1 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ checkinstall ]
7 -  Architecture: [ amd64 ]
8 -  Source location: [ hello-2.10 ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ hello ]
12 - Conflicts: [  ]
13 - Replaces: [  ]
Geben Sie die betreffende Nummer ein, um die Vorgaben zu ändern:

[...]
Kopiere Dateien in das temporäre Verzeichnis...OK
Stripping ELF binaries and libraries...OK
Komprimiere man-Seiten...OK
Erzeuge Datei-Liste...OK
Erstelle Debian-Paket...OK
Installiere Debian-Paket...OK
Lösche temporäre Dateien...OK
Schreibe Sicherungs-Paket...OK
Lösche temporäres Verzeichnis...OK
**********************************************************************
 Done. The new package has been installed and saved to
 /tmp/hello-2.10/hello_2.10-1-1_amd64.deb
 You can remove it from your system anytime using:
      dpkg -r hello
**********************************************************************

Letztendlich liegt Hello nun kompiliert und bereit zum Aufruf auf der Festplatte. Die Eingabe eines hello in der Shell begrüßt Sie mit einem freudigen Hallo, Welt! – mehr macht das Demo-Programm jedoch auch nicht. Die Kontrolle mit apt-cache policy zeigt, dass das Paket die gewünschte Versionsnummer trägt und lokal installiert wurde (Listing 5). Benötigen Sie das Programm nicht mehr, deinstallieren Sie es wie jedes andere Programm über die Paketverwaltung.

$ hello
Hallo, Welt!
$ apt-cache policy hello
hello:
  Installiert:           2.10-1-1
  Installationskandidat: 2.10-1-1
  Versionstabelle:
 *** 2.10-1-1 0
        100 /var/lib/dpkg/status
     2.9-2 0
        500 http://de.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages
$ sudo apt-get remove hello
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
  hello
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 202 nicht aktualisiert.
Nach dieser Operation werden 913 kB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n]

Fazit

Checkinstall hilft, das System bei der Installation fremder Software sauber zu halten. Anstatt mit einem make install die Software “wild” im System zu installieren, listet die Paketverwaltung die mit Checkinstall in eigener Regie erstellten Pakete auf, sodass diese sich bei Bedarf auch wieder sauber deinstallieren lassen. Zudem können Sie das Paket ohne zusätzlichen Aufwand auf weiteren Rechnern nutzen oder an Freunde und Bekannte weitergeben. Doch das Hantieren mit Checkinstall oder das Kompilieren von Software aus dem Quellcode zeigt besonders Einsteigern schnell die Grenzen des eigenen Handelns auf.

Checkinstall eignet sich in der Regel nur für einfache Programme mit keinen oder wenigen Abhängigkeiten, die zudem nicht auf Pre- und Post-Install-Skripte angewiesen sind. Wer meint, eben einmal schnell ganze Desktop-Umgebungen oder große Anwendungen wie LibreOffice eigenständig kompilieren zu können, der liegt falsch – aus der Abhängigkeitenhölle hilft auch Checkinstall nicht heraus. Für den Hausgebrauch beim Bauen kleiner Programme macht es jedoch eine gute Figur und kommt daher auch bei Linux-Profis für Quick-and-Dirty-Pakete zum Einsatz.

Einige Anleitungen im Internet empfehlen, mit Checkinstall erstellte Pakete zur Weitergabe an eine Community durchzureichen. Die Qualität und Vollständigkeit der erzeugten Pakete genügt jedoch selten gehobenen Ansprüchen. Für solche Fälle sollten Sie sich mit alternativen Methoden des Paketbaus beschäftigen, wie etwa mit buildpackage [5]. Diese gewährleisten unter anderem durch die korrekte Definition von Abhängigkeiten, dass das Paket auf verschiedenen Rechnern korrekt arbeitet.