The Answer Girl: FreeBSD-Zusatzsoftware installieren und entfernen

Das Software-Angebot für FreeBSD ist riesig, doch müssen sich Linux-User bei Installieren und Deinstallieren etwas umstellen: Die sogenannte Ports-Kollektion hat es in sich.

The Answer Girl

Dass der Computeralltag auch auf Unix-Systemen des Öfteren Überraschungen bereit hält, ist eher eine Binsenweisheit: Immer wieder funktionieren Dinge nicht oder nicht so, wie eigentlich angenommen. Das Answer-Girl im LinuxUser zeigt, wie man mit solchen Problemchen elegant fertig wird.

Die ersten Schritte [1,2] in der Welt des FreeBSD-Teufelchens, Verzeihung! -Dämons, waren vielleicht noch etwas wacklig. Doch gibt es – Unix ist Unix – die meisten von Linux gewohnten Kommandozeilenbefehle auch hier, und KDE sieht nicht anders aus, sondern startet einfach nur viel schneller. Wer sich davon einmal vergewissert hat, will allerdings irgendwann mehr: neue Programme oder unter Linux liebgewordene Software nachinstallieren.

Abbildung 1: Leicht zu übersehen: der sysinstall-Index

Das einzige Problem dabei: Kein aus der Linux-Welt bekannter Paketmanager – weder rpm noch apt-get, weder yast noch kpackage – lässt sich finden. Die Linuxerin steht ein wenig ratlos da. Zum Glück bietet das altbekannte, als root aufgerufene Werkzeug /stand/sysinstall wie bei so vielen die Installation und Konfiguration betreffenden Problemen den Schlüssel zur Lösung. Vielversprechend sieht der letzte Punkt des Main Menu namens Index aus, der ein Funktionsglossar verheißt (Abbildung 1). Tatsächlich bietet sysinstall auf dessen Anwahl hin eine alphabetische Liste kurz erklärter Stichpunkte an, die sich wiederum mit der [Enter]-Taste auswählen lassen (Abbildung 2).

Abbildung 2: Im “Glossary of functions” von sysinstall sieht der Punkt “Packages” vielversprechend aus

Ein Index zahlt sich aus

Dabei sieht der Punkt Packages nach einem Lösungsansatz aus. Tatsächlich fragt sysinstall nach dessen Anwahl nach einem Installationsmedium. Wer seinen Rechner ans Internet angebunden hat, wird hier meist den Punkt FTP sowie einen Server in heimatlichen Gefilden auswählen. Auch die Abfrage, ob das Netzwerk bereits konfiguriert ist, dürfte dann leicht mit dem Yes-Pseudobutton zu beantworten sein.

Abbildung 3: Welches Paket soll es sein?

sysinstall lädt einen Paket-Index herunter (je nach eigener Netzanbindung und der des gewählten Servers kann das eine Weile dauern) und bietet das Package Selection-Menü an, in dem es sich nun tatsächlich nach Software-Paketen stöbern lässt: Aus-, an- und abwählen mit [Enter], navigieren in den Listen mit den Pfeiltasten und [Tab] zum Wechsel auf die Pseudoknöpfe – diese Bedienung gilt auch hier. Nach der Paketauswahl, etwa von converters / tnef2txt-1.4 (Abbildung 3), führt ein Druck auf OK zurück ins Package Selection-Menü.

Hat man alles zusammengesucht, gibt die Anwahl des dortigen Install-Knopfes den Startschuss zur Installation (im Beispiel des Konverters für Outlooks ominöse Microsoft-tnef-Mail-Attachments). Mit einem Druck auf den Cancel-Button aus Abbildung 4 bleibt noch die Möglichkeit eines schnellen Rückziehers. Ansonsten ist der Weg frei zur Installation des passenden Pakets – am Ende lässt sich das tnef2txt-Programm einfach auf der Kommandozeile aufrufen.

Abbildung 4: Installiert werde tnef2txt!

Und wenn die Binärinstallation scheitert?

Wenn das so einfach ist mit dem Installieren … Mutig geworden soll auch afterstep / afterstep-i18n-1.0_1 als neuer Windowmanager auf’s System. Doch statt zu installieren, streikt sysinstall beim Einspielen des freetype2-Pakets, von dem aftersteps Funktionalität offensichtlich abhängt:

Add of package freetype2-2.1.2 aborted, error code 1

lautet die ebenso unfrohe wie wenig Hilfe bietende Mitteilung. Doch so gut es zu wissen ist, dass sich sysinstall der Paketabhängigkeiten einer einzuspielenden Software annimmt, nützt dies wenig, wenn die Anwenderin nun auf die gewünschte Software verzichten muss.

Da muss es andere Wege geben … Moment, warum steht in den Dialogen aus Abbildung 3 wie 4 eigentlich jedes Mal so ein komischer Pfad in eckigen Klammern hinter dem Paketnamen? Das Stichwort ports darin lässt Erinnerungen an die Installation des Systems wach werden [1]. Offensichtlich enthält das Verzeichnis /usr/ports die nötigen Informationen zu der riesigen Menge für FreeBSD angepasster Software, der “Ports Collection”.

Ein Blick mit ls in dieses Verzeichnis offenbart eine Menge Verzeichnisse, in denen – nach Kategorien sortiert – Unterverzeichnisse für diverse Software-Pakete liegen. Nicht immer stimmt diese Kategorisierung mit der in sysinstall überein: So befindet sich das tnef2txt-Verzeichnis laut Abbildung 3 im textproc-Unterverzeichnis der Ports-Kollektion, während sysinstall es in die Kategorie converters einordnet. Aber, und das ist das Entscheidende, sysinstall listet immer das passende Ports-Verzeichnis auf.

Für die internationalisierte Version von afterstep wechselt die installierwillige Systemadministratorin also nach /usr/ports/x11-wm/afterstep-i18n. Dort liegen, wie ls zeigt, bereits eine Menge Dateien herum, etwa pkg-descr, die den Inhalt des Pakets beschreibt, oder pkg-plist, aus der man erfährt, welche Dateien das Paket bei seiner Installation im System verstreuen wird.

Die Datei distinfo enthält MD5-Prüfsummen, doch das darin erwähnte Paket AfterStep-1.0.tar.gz ist nirgends zu finden, nicht einmal im files-Unterverzeichnis, in dem offensichtlich einige Patches für die Software herumliegen. Doch gibt es eine Datei namens Makefile im Paketverzeichnis, und das heißt, dass der Befehl make ganz sicher etwas tun wird, wenn man ihn im aktuellen Verzeichnis aufruft.

Einmal make und zurück

… und zwar eine ganze Menge: Die passenden Quellcode-Pakete aus dem Internet ziehen, die Prüfsummen vergleichen, entpacken, Patches einspielen, konfigurieren und letztlich kompilieren. Wenn’s keine Fehlermeldungen gibt (Kasten 1 zeigt einen Problemfall), dauert das ganze Prozedere lediglich eine Weile und lässt die Anwenderin mit einem neuen Verzeichnis namens work zurück, in dem Quellcode und Kompilat zu finden sind.

Kasten 1: Selbstkompilieren versus Binärpakete

Wer seine Software selbst aus dem Sourcecode kompiliert, hat einen Vorteil gegenüber den Installateuren von Binärpaketen: Letztere sind auf Gedeih und Verderb darauf angewiesen, dass die bei ihnen installierten Bibliotheken und Zusatzprogramme im Binärformat zu den einzuspielenden Paketen passen. Oft reicht es schon, dass der Distributor eine andere Compiler-Version zum Übersetzen der Systembestandteile benutzt hat als der Ersteller des neuen Softwarepakets, damit der Traum vom Einspielen desselben platzt. (Red-Hat-Linux-Benutzer, die SuSE-Linux-RPMs einspielen wollen und umgekehrt, können ein Lied davon singen.)

Selbstkompilierer sind da flexibler: Hier muss die Software mit den Bibliotheken lediglich an den Quellcode-Schnittstellen zusammen passen – ob sich dahinter etwas geändert hat, ist uninteressant. Man spricht dabei von Source-Kompatibilität, die sich sehr viel leichter erreichen lässt als Binärkompatibilität.

Da für FreeBSD hin und wieder Anpassungen am Original-Quellcode nötig (oder einfach nur vorteilhaft) sind und die FreeBSD-Entwickler bei den vielen Paketen nicht jedes im Original veränderte Byte mitverfolgen, kann es dennoch zu Problemen kommen. Beispielsweise dann, wenn so wie im Folgenden bei Galeon der Patch aus der Ports-Kollektion abgewiesen (“rejected”) wird:

===>  Patching for galeon-1.2.6
===>  Applying FreeBSD patches for galeon-1.2.6
2 out of 2 hunks failed--saving rejects to src/mozilla/mozilla.cpp.rej
4 out of 4 hunks failed--saving rejects to src/mozilla/ContentHandler.cpp.rej
5 out of 5 hunks failed--saving rejects to src/mozilla/FilePicker.cpp.rej
[…]
5 out of 5 hunks failed--saving rejects to src/mozilla/ProgressListener2.cpp.rej
>> Patch patch-1.0.rc3 failed to apply cleanly.
 * Error code 1
Stop in /usr/ports/www/galeon.

Die Patch-Datei patch-1.0.rc3 aus dem files-Unterverzeichnis des Galeon-Port-Directories enthält dabei Korrekturen für mehrere Quellcode-Dateien aus dem galeon-1.2.6-Sourcecode-Archiv. Einige dieser hunks genannten Einzeländerungen lassen sich dabei nicht einspielen, weil der Patch im Vergleich mit einer anderen Version des Quelltextes (oder auch falsch) erstellt wurde und das patch-Programm nun die zu korrigierenden Zeilen nicht mehr findet.

Doch auch dann muss ein nichtprogrammierender User nicht sofort alle Hoffnung verlieren: Nicht alle Patches aus dem files-Directory sind lebenswichtig, und so lohnt sich oft der Versuch, dieses Verzeichnis etwa mit mv files Files so umzubenennen, dass die Patches nicht gefunden werden. Weniger rabiate Naturen nehmen einfach nur die problematische Patch-Datei aus der Schusslinie:

mkdir Files
mv files/patch-1.0.rc3 Files

Wenn ein erneutes make immer noch keinen Erfolg bringt (etwa weil Galeon GNOME braucht, dessen Installation aber ebenfalls nicht von Erfolg gekrönt ist), bleibt letztlich nur die Entscheidung: Aufgeben oder sich eine lange Nacht lang dem Try-and-Error-Prinzip widmen.

Da bislang keine der in pkg-plist aufgeführten Dateien außerhalb des Ports-Verzeichnisses gelandet sind, steht fest, dass die kompilierte Software noch nicht auf dem System installiert wurde. Weil zum Einspielen aus dem Quellcode übersetzter Anwendungen in der Linux-Welt meist der Befehl make install zum Einsatz kommt, liegt es nahe, root einen gleichlautenden Versuch starten zu lassen. Dass er erfolgreich war, zeigt die Probe mit dem Kommando which afterstep: Vor der Installation gibt which die Fehlermeldung Command not found zurück; nach dem make install den neuen Pfad des installierten Windowmanagers, /usr/X11R6/bin/afterstep.

Leider hat die Kompiliererei einen großen Nachteil: Die Festplatte verstopft leicht mit all den beim Kompilieren erzeugten Objektdateien und natürlich auch den ausgepackten Quelltextarchiven selbst. Sobald make install seinen Dienst getan hat, kann also saubergemacht werden. Wie nicht anders zu erwarten, gibt es auch hier ein spezielles make-“Target”: make clean im jeweiligen Ports-Verzeichnis räumt gründlich auf, was sich daran sehen lässt, dass das work-Unterverzeichnis komplett gelöscht wird. Doch das ist nicht alles: Auch vor den Katalogen von Paketen, die mitkompiliert wurden, um Abhängigkeiten zu befriedigen, macht die Säuberungsaktion nicht halt.

Weg damit!

Was einmal installiert ist, muss das nicht ewig bleiben: So, wie es zum Installieren zwei Wege – den über das Selbstkompilieren im Ports-Verzeichnis und über sysinstall – gibt, hat man auch beim Deinstallieren die Wahl. Tatsächlich erweist sich das Ports-System hier als sehr viel flexibler als die Paketmanager der großen Linux-Distributionen: Ob man den Port selbst kompiliert oder ein vorgefertigtes Paket via sysinstall eingespielt hat, in beiden Fällen kann man sysinstall aufrufen und das Häkchen im Package-Menü wieder entfernen. Und weil das für ein einzelnes Paket dank des mühseligen User-Interfaces doch etwas zeitraubend ist, reicht es auch, ins passende Ports-Verzeichnis zu wandern und die Software mit einem einfachen make deinstall aus den Systemverzeichnissen zu entfernen (Listing 1).

Listing 1

Deinstallieren eines Ports

testmaskin# which tnef2txt
/usr/local/bin/tnef2txt
testmaskin# cd /usr/ports/textproc/tnef2txt
testmaskin# make deinstall
===>  Deinstalling for tnef2txt-1.4
testmaskin# which tnef2txt
tnef2txt: Command not found.
        @KE:

Glossar

apt-get: Das wichtigste Paketverwaltungstool der Debian-Distribution [3,4].
internationalisiert: Das Anpassen einer Software, so dass sie in andere Sprachen übersetzt (“lokalisiert”) werden kann. Das Wortungetüm wird oft mit “i18n” abgekürzt, also ein i, darauf folgende 18 Buchstaben (“nternationalizatio”) und ein abschließendes n.
Patches: Flicken für eine Software; im Falle von FreeBSD-Ports oft Quellcode-Änderungen, die den Original-Sourcecode an FreeBSD anpassen. Zum Einspielen der Patch-Dateien, die die Differenzen zwischen dem originalen und dem angepassten Quellcode enthalten, kommt das Programm “patch” zum Einsatz.
Makefile: Findet “make” im aktuellen Verzeichnis eine Datei namens “makefile” oder “Makefile” vor, führt es die darin aufgeführten Kommandos entsprechend den dort festgelegten Regeln aus. Das Makefile legt auch fest, welche Argumente (“Targets”) “make” in diesem Fall kennt (zum Beispiel “install”, “deinstall” oder “clean”). Dass in den Makefiles der Ports-Kollektion keines der in diesem Artikel vorgestellten Targets zu finden ist, liegt an einer anderen Eigenschaft derselben: Sie können ihrerseits anderswo untergebrachte Regelwerke einlesen (“include”) – alles eine Frage der Regeln.