Handgemacht

Installation mit Hinternissen

Fehler beim Aufruf von make install gibt es fast nie. Meistens treten sie auf, wenn Sie ein Programm in ein anderes Verzeichnis installieren als nach /usr/local. Soll eine Anwendung in /usr/local/test landen, scheitert manchmal das Kopieren der Dateien daran, dass der Programmierer vergessen hat, im Makefile die Befehle einzutragen, die die Zielverzeichnisse erstellen.

Solange /usr/local/test/bin noch nicht existiert, schlägt jeder Versuch fehl, eine Datei dorthin zu kopieren. Am schnellsten beseitigen Sie solche Fehler, indem Sie die Zielverzeichnisse, die Sie aus der Fehlermeldung ersehen, mit mkdir selbst erstellen.

Ärger nach der Installation

Ist das Selbstkompilat erst installiert, folgt beim Start einer neuen KDE-Anwendung oft Ernüchterung: Das Programm findet seine Plugins nicht, präsentiert sich mit nackter Werkzeugleiste ohne Icons und spricht natürlich auch kein Deutsch (Abbildung 2). Per Default suchen KDE-Anwendungen nämlich nur unterhalb des Verzeichnisses, in dem die KDE-Kernanwendungen samt Zubehör liegen, nach ihren Daten. Unter Suse Linux heißt dieses KDE-Verzeichnis /opt/kde3, unter Red Hat und Mandrake Linux /usr. Bei selbst übersetzten KDE-Anwendungen wandern die Icons, Plugins und Hilfe-Dateien jedoch nach /usr/local.

In Web-Foren erhalten Fragesteller bei diesem Problem meistens den Rat, die Anwendung erneut zu übersetzen und dieses Mal beim ./configure-Aufruf das KDE-Verzeichnis als Installationsziel anzugeben, z. B. mit ./configure --prefix=/opt/kde3.

Obwohl die Anwendungen danach wie erwartet funktionieren, ist diese Lösung nicht ideal, sondern mitunter sogar gefährlich. Das Verzeichnis /opt/kde3 gehört bei Suse ebenso wie /usr unter Red Hat und Mandrake Linux der Paketverwaltung. Eigenkompilate haben dort nichts zu suchen, denn die Paketverwaltung kann selbst übersetzte Software nicht entfernen. Bei einem Distributions- oder KDE-Update können diese Dateien zu einem instabilen KDE führen. An die selbstkompilierten Anwendungen erinnert man sich zu diesem Zeitpunkt meistens nicht, und selbst wenn, hat man kaum eine Chance, den Störenfried aufzuspüren.

Die saubere Lösung besteht darin, seinen KDE-Programmen mitzuteilen, dass es noch ein weiteres Datenverzeichnis gibt. Das geht über die Umgebungsvariable KDEDIRS. Der Befehl

export KDEDIRS=/usr/local:/opt/kde3

setzt sie auf die beiden für Suse Linux relevanten Verzeichnisse: /usr/local, wo selbst kompilierte Software landet, und /opt/kde3, wo das Distributions-KDE liegt. Der passende Befehl unter Red Hat und Mandrake Linux lautet export KDEDIRS=/usr/local:/usr.

Aus dem so präparierten Kommandozeilenfenster gestartet, halten KDE-Anwendungen nun auch unterhalb von /usr/local nach ihren Daten Ausschau. Wollen Sie die Umgebungsvariable dauerhaft setzen, ist die Datei .bash_profile in Ihrem /home-Verzeichnis der richtige Ort. Befehle, die Sie dort eintragen, führt die Bash aus, sobald Sie sich am System anmelden.

Ein wenig mehr Arbeit wartet auf Suse-Linux-Nutzer, da dort der Befehl

unset KDEDIRS

in der Datei /opt/kde3/bin/startkde steht. Dieses Shell-Skript startet den KDE-Desktop. unset löscht den Inhalt von Umgebungsvariablen und ist damit ein Gegenstück zu export. Da das Skript ~/.bash_profile vor dem Start des Desktops ausgeführt wird, erfährt KDE gar nicht, dass es noch ein weiteres Datenverzeichnis gibt.

Um auch unter Suse Linux die Variable zu setzen, öffnen Sie die Datei /opt/kde3/bin/startkde als root mit einem Editor und setzen vor die Zeile unset KDEDIRS eine Raute (#). Sie gilt als Kommentarzeichen, so dass die Shell den Rest der Zeile nicht ausführt. Wollen Sie die Änderung später einmal rückgängig machen, entfernen Sie das Zeichen einfach.

Abbildung 2: Ein nach /usr/local installiertes K3b findet weder seine Icons noch die Plugins.