The Answer Girl
Dass der Computeralltag auch unter Linux des Öfteren für Überraschungen gut ist, 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.
Wer ausschließlich für die jeweilige Distribution vorkompilierte rpm- oder deb-Pakete mit dem vorgesehenen Paketmanager installiert, tut dies im Bewusstsein, sie bei Bedarf auf gleichem Wege auch wieder rückstandslos entfernen zu können. Selbst wenn "Leichen" auf dem System verbleiben, bleibt immer noch das gute Gefühl der eigenen Unschuld: In dem Fall hat der Paket-Packer schlampig gearbeitet.
Doch selbst softwaremäßig gut bestückte Distributionen müssen irgendwann passen: Nicht jedes nützliche Programm gibt es für alle Distributionen und Distributionsversionen fertig vorkonfektioniert. Sobald es "Selbstkompilieren" heißt, kommt spätestens beim make install die Stunde der Wahrheit: Wer hier nicht genauestens Buch führt, findet zwar sicherlich das installierte Binary und eventuell auch die entsprechende Manpage wieder, doch war das tatsächlich alles, was dieses unscheinbare Kommando, mit root-Rechten ausgeführt, in den Weiten des Dateisystems versteckt hat?
Arbeitsverbot für make
Immerhin gibt es auch zu make eine Manpage, und die erklärt, dass die Option -n alle Kommandos auflistet, die während der Abarbeitung des Makefile zum Zuge kommen, jedoch auf deren Ausführung verzichtet. Kein Problem, solange diese Liste einfach und übersichtlich ist wie beim mirror-Paket:
pjung@chekov:~/software/mirror$ make -n install[…] install -m 755 -g gnu mirror.pl /usr/local/sbin/mirror[…]
Hier wird lediglich das install-Kommando aufgerufen, das die Datei mirror.pl ins Zielverzeichnis /usr/local/sbin kopiert und gleichzeitig in mirror umbenannt. Dort bekommt sie dank der Modus-Option -m 755 die Rechte rwxr-xr-x und wird mit -g der Gruppe gnu (die bereits vorhanden sein muss) zugeordnet.
Kopiert man die von make install auszuführenden Kommandos mit dem Umleitungsoperator > in eine zu archivierende Datei (make -n install > dateiname), kann man bei späteren Deinstallationsanwallungen den Installationsprozess rekonstruieren und /usr/local/sbin/mirror und Konsorten per Hand mit dem rm-Kommando aus dem System entfernen.
Sobald make install jedoch längliche, hochkomplexe Shell-Skripte ausführen soll, die ihrerseits wieder auf im Quellpaket mitgelieferte Skripte zurückgreifen, reicht der Wille zur Disziplin sicherlich nicht mehr aus. Ein anderer Ansatz muss her.
Jedem das seine Verzeichnis
Die einfachste Lösung wäre, jede selbstkompilierte Software in einem jeweils eigenen Verzeichnis unterzubringen. Der "Filesystem Hierarchy Standard" (http://www.pathname.com/fhs/) schlägt hier /opt/Paketname für "add-on application software packages", zusätzliche Anwendersoftware, vor. Sinnvoll ist jedoch auch die Alternative eines Paketverzeichnisses unterhalb von /usr/local, selbst wenn dies im FHS nicht vorgesehen ist.
In diesem Paketverzeichnis sollte dann wieder eine typische Unix-Verzeichnishierarchie mit bin-Verzeichnis für User-Programme, sbin für der Systemverwalterin root vorbehaltene Binaries, man für Manpages, lib für Bibliotheken, include für eventuelle Header-Files etc. angelegt werden, soweit das jeweilige Softwarepaket passende Dateien mitbringt.
Doch wie überzeugt man make install, in solch ein Verzeichnis hineinzukopieren? Anscheinend, indem man die Datei makefile oder Makefile modifiziert. Eine Sicherheitskopie angelegt, gilt es, nach dem Target ("Ziel") install zu suchen. Das Makefile bestimmt nämlich, mit welchen Argumenten make aufgerufen werden kann: Nur Wörter, die darin am Anfang einer Zeile stehen und von einem Doppelpunkt beendet werden, sind erlaubt. Das makefile aus dem mirror-Paket ist recht übersichtlich:
install:[…]
install -m $(EXMODE) -g $(GRP) mirror.pl $(BINDIR)/mirror[…]
Hier finden wir, von genau einem Tabulatorzeichen eingerückt, die von make install auszuführenden Kommandos wieder – allerdings sind konkrete Werte durch Variablen ersetzt. Ein Vergleich zeigt, dass $(BINDIR) offensichtlich den Inhalt der Variablen BINDIR an dieser Stelle einfügt, und BINDIR bekommt einige Zeilen weiter oben den Wert /usr/local/sbin zugewiesen:
# directory to install public executables BINDIR = /usr/local/sbin
Wollen wir das "Verzeichnis, in dem öffentlich zugängliche ausführbare Dateien" abgelegt werden, in /opt/mirror/sbin ändern, verlangt das lediglich eine Korrektur im makefile:
BINDIR = /opt/mirror/sbin
Die Herausforderung bei dieser Verfahrensweise besteht lediglich darin, alle Variablen herauszufinden, die sich auf den Installationsschritt beziehen. Das kann in Friemelarbeit ausarten, bei der viele Kontrollläufe in Form von make -n install nötig werden. Bei solchen handgeschriebenen Makefiles kommt es auch des Öfteren vor, dass der Autor nicht sauber gearbeitet und "versehentlich" statische Pfadangaben mit eingebaut haben. Hier hilft nur die konsequente Suche nach der hartnäckigen Verzeichnisangabe.
Ein Problem kommt hinzu: Wenn sich make install mit einer Fehlermeldung der Art
install: cannot create regular file `/opt/mirror/sbin': No such file or directory
beschwert, fehlt das Zielverzeichnis /opt/mirror/sbin, das per Hand angelegt werden muss. Fehlt nicht nur das letzte Unterverzeichnis sbin, sondern auch sein übergeordnetes Directory mirror, erspart man sich einen mkdir-Befehl, wenn man mit
mkdir -p /opt/mirror/sbin
alle nötigen Eltern-("parent"-)Verzeichnisse mit einem Mal anlegt.



