Auf eigene Gefahr?

Installationsmanager

Neben diesen Anfängen des dateizentrischen Ansatzes steht bei allen Distributionen der unter Linux gängige, programmzentrische Weg zur Auswahl: Dieser führt vom Aufruf des Installations- oder Softwaremanagers über die Wahl des gewünschten Programms zur Installation. Fedora und Xandros sehen ihn als den einzigen "normalen" Weg an, bei Suse/YaST bietet er zahlreiche Einstellungs- und Kontrollmöglichkeiten, bei Mandrake fällt er sehr eingeschränkt aus.

So implementiert Suse die Software-Verwaltung als einen Teil von YaST. Leider bietet das unter SoftwareSoftware installieren oder löschen zu findende Installationsmodul keine Möglichkeit, eine auf der lokalen Festplatte liegende RPM-Datei auszuwählen. Zwar gibt es den Menüpunkt DateiImportieren..., doch verlangt dieser nach Paketlisten im (nicht näher beschriebenen) *.sel-Format.

Die kaum intuitiv zu nennende Lösung besteht darin, unter SoftwareInstallationsquelle wechseln über HinzufügenLokales Verzeichnis... eine neue Installationsquelle einzurichten. Damit YaST deren Inhalt findet, muss man das Installationsmodul anschließend erneut aufrufen. Dessen Handhabung gestaltet sich sehr umständlich und alles andere als intuitiv. So sieht man z. B. verschiedene Versionen eines Programms nicht auf Anhieb, und Software-Updates gelingen nur durch Ausprobieren.

Mandrake trennt ebenfalls zwischen der Installation über eine Datei (RPM) und einen Software-Installer. Letzterer bietet gegenüber YaST weniger Informations- und Kontrollmöglichkeiten. Verlief die Suche nach einem Programm ergebnislos, steht der Benutzer vor dem Rätsel: "Gab es kein Ergebnis oder habe ich einfach nur vergessen, die Suche zu starten?" Weiterhin konfrontiert Mandrake ihn mit unverständlichen technischen Gerätebezeichnungen (Abbildung 2).

Abbildung 2: Welches Laufwerk ist gemeint, wenn man auf einem Mandrake-System zwei CD-ROMs hat?

Die Installer von Fedora und Xandros bieten eine Liste aller verfügbaren Programme an. Deren Auswahl fällt bei beiden leicht, jedoch fehlt die Angabe, um welche Version der Software es sich handelt (Abbildung 3). Eine Möglichkeit, ein lokales Verzeichnis als Paketquelle anzugeben, existiert bei beiden nicht.

Abbildung 3: Handelt es sich um Gimp 1.2 oder Gimp 2? Versionsangaben fehlen bei Fedoras Installer.

Konfliktfälle

Bedingt durch die Paketabhängigkeiten (siehe Kasten 1) treten unter Linux Schwierigkeiten auf, die Windows-Nutzer so nicht kennen. Dann kommt es darauf an, wie die Software Konflikte kommuniziert und löst, und welche Hilfestellungen der Nutzer erhält.

Was zum Beispiel passiert im häufig auftretenden Fall, dass Bibliotheken auf der Festplatte fehlen und aus dem Internet oder von CD/DVD nachinstalliert werden müssen? Wie reagiert der Installer, wenn benötigte Bibliotheken mit bereits installierten, eventuell notwendigen Paketen in Konflikt stehen?

Suses YaST installiert fehlende Bibliotheken (teilweise auf Nachfrage) nach, zunächst jedoch nur von der CD/DVD. Will man auch aus dem Internet Pakete nachladen, muss man passende Installationsquellen einrichten. Auch wer die Systeminstallation per DVD durchführt und für die Nachinstallation eine CD einlegt, muss Suse dies manuell beibringen.

Mit einem ausführlichen "Konfliktdialog", der dem Nutzer verschiedene Optionen anbietet, reagiert YaST auf den zweiten Problemfall. Allerdings macht das Programm weder klar, worin die Schwierigkeit besteht, noch wodurch sie zustande kommt (Abbildung 4). Nicht immer muss es sich dabei tatsächlich um einen Konflikt handeln. Manchmal findet YaST lediglich Pakete nicht, suggeriert aber ein Szenario, das zur Systeminkonsistenz führen kann.

Eine positive automatische Lösung – etwa das Herunterladen und die Nachinstallation aller notwendigen Pakete aus geeigneten Quellen – bietet YaST nicht an. An dieser Stelle bleibt "normalen" Nutzern nur die Möglichkeit abzubrechen, denn Hilfe oder zusätzliche Informationen finden sie nicht.

Abbildung 4: Der Konfliktdialog von YaST verwirrt durch ein schwaches Design und missverständliche Texte.

Mandrakes RPMDrake liefert im Konfliktfall generell wenig verständliche Anhaltspunkte, installiert Pakete nicht nach und lässt den Nutzer weitestgehend alleine (Abbildung 5).

Abbildung 5: Ungelöste Paketkonflikte bei Mandrake bleiben ungelöst.

Fedora umgeht diese Probleme, indem es über den Installationsmanager nur jene Software anbietet, die mitgeliefert wurde oder per Online-Update bereitsteht und damit konfliktfrei sein sollte. Für den Nutzer geht alles einfach und glatt, allerdings zum Preis eines geschlossenen und eingeschränkten Systems.

Xandros kennt ebenfalls keine Konflikte, solange man sich auf das Angebot des Xandros Network beschränkt. Dennoch gibt es auch hier zuweilen unverständliche Warnhinweise (Abbildung 6). Spielt man dagegen ein RPM (in unserem Beispiel KDevelop von der lokalen Festplatte) ein, so kann es passieren, dass die Installation "erfolgreich" verläuft. Tatsächlich lässt sich das Programm aber nicht starten, weil die benötigten Bibliotheken nicht mitinstalliert wurden.

Fairerweise sei angemerkt, dass Xandros nativ auf das Debian-Paketformat setzt und daher mit dem Debian-Tool apt-get einen smarten Installationsmechanismus nutzt. Anders als für die anderen Distributionen gibt es keine für Xandros gebauten RPM-Pakete. Stattdessen greift der Distributor auf den Konverter alien zurück. Stimmen die im RPM-Paket vermerkten Abhängigkeiten nicht mit den Namen der entsprechenden Debian- bzw. Xandros-Pakete überein, hat dieser keine Möglichkeit, sie herauszufinden.

Abbildung 6: Auch bei Xandros kann es zu Problemen kommen. Leider ist deren Beschreibung nicht sehr aufschlussreich.