Will ein Anwender Software installieren, die der Distributor nicht auf der Installations-DVD oder online liefert, ist oft Handarbeit angesagt. Wie gut die Debian- und Suse-Tools den Benutzer dabei unterstützen und wie gut sich der Smart-Paketmanager als Alternative eignet, testet diese Bitparade

Die Paketverwaltung unter Linux zeigt sich im Vergleich mit anderen Betriebssystemen leistungsstark: Die DVD oder Online-Repositories einer Linux-Distribution enthalten Hunderte, oft Tausende in ihrem Zusammenspiel getestete Softwarepakete. Abhängigkeiten wie Bibliotheken schließt der Paktemanager beim Installieren neuer Pakete automatisch ein. Da er jede Datei säuberlich in einer Datenbank registriert, lässt sich Software anders als unter Windows auch wieder rückstandsfrei entfernen. Ein unkontrolliertes Überschreiben von Bibliotheken lässt der Paketmanager nicht zu – die Windows-DLL-Hölle ist unter Linux ein Fremdwort.

Doch trügerisch ist jede Idylle. Was die Paketverwaltung unter Linux angeht, hat sie nur so lange Bestand, wie der Benutzer bei der vom Linux-Distributor zur Verfügung gestellten Software bleibt. Richtet er seinen Blick aber auf verbotene, sprich vom Distributor nicht vorgesehene Früchte, muss er diese meist im Schweiße seines Angesichts installieren. Diese Bitparade konfrontiert die Paketverwaltungslösungen von Debian, Ubuntu und Suse sowie den nicht an eine Distribution gebundenen Paketmanager Smart mit fünf Praxisszenarien.

Die Kandidaten

Bei den Paketverwaltungssystemen haben Debian Linux und dessen Derivate den besten Ruf: Apt-get gilt als schnell und zuverlässig. Im Test zeigt er aber nur beschränkte Intelligenz beim Auflösen von Paketabhängigkeiten (Abbildung 1). Dies gilt ebenso für das X-Window-Programm Synaptic. Nicht zu Unrecht löst mit Debian Etch das Kommandozeilen-Tool Aptitude Apt als “bevorzugte Methode zur Paketverwaltung” ab [1]. Außer dem gewöhnlichen Kommandozeilen-Interface bietet Aptitude auch eine Ncurses-Oberfläche (Abbildung 2).

Abbildung 1: Schnell, aber nicht klug: Apt-get leistet sich deutliche Schwächen beim Auflösen der Paketabhängigkeiten. Die Fehlermeldung verschleiert zudem den Grund, warum sich ein Paket nicht installieren lässt.

Abbildung 2: Würdiger Erbe: Ab Debian 4.0 ersetzt Aptitude Apt als Standard-Paketmanager. Die neue Anwendung löst Abhängigkeiten besser auf und bietet außer dem Kommandozeilen-Interface auch ein Ncurses-basiertes GUI.

Unter Open Suse gilt die Paketverwaltung seit Version 10.1 als Sorgenkind: Das Einführen des neuen Dependency-Solvers Libzypp in der fortgeschrittenen Betaphase [2] führte zu einem äußerst trägen und zudem instabilen »Software«-Modul von Yast (Abbildung 3). So viele Benutzer stiegen auf Apt für RPM um – einem Port des Debian-Dependency-Solvers für RPM-Systeme -, dass von Suse unabhängige Repositories ihre Software überwiegend im zugehörigen Repository-Format bereitstellten.

Abbildung 3: Sorgenkind: Zwar bietet das Yast-Modul »Software« viele Funktionen und lässt dem Benutzer viel Freiheit. Doch selbst nach den Performance-Nachbesserungen in Open Suse 10.3 kostet die Paketverwaltung Zeit und Nerven.

Der Smart-Paketmanger [3] überrascht zunächst damit, dass er auf vielen Distributionen läuft. Die überwiegend in Python geschriebene Software nutzt die distributionseigenen Manager wie RPM oder Dpkg als Basis, enthält aber eigene Algorithmen für die Auflösung der Abhängigkeiten. Smart versteht auch viele Repository-Formate. Er bindet Yast-, Yum-, Redcarpet- und Urpme-Repositories ebenso ein wie RPM- oder Debian-Pakete, die in lokalen Verzeichnissen ohne Repository-Struktur liegen.

Auch mit Smart lassen sich jedoch Softwarepakete in der Regel nur auf jener Distribution installieren, für die sie konzipiert sind. Immerhin bietet die Software für viele Linux-Distributionen ein gleichbleibendes Kommandozeilen- und GUI-Interface (Abbildung 4).

Abbildung 4: Vielversprechende Ansätze, insgesamt allerdings noch im Betastadium. Der Smart-Paketmanager trägt seinen Namen zu Recht, leistet sich aber gelegentlich noch Programmabstürze.

Szenario 1

Der Anwender hat die Bibliothek XYZ in der neuesten Version kompiliert, die wichtige Verbesserungen bietet oder Sicherheitslücken schließt. Nach der Installation und – falls »make install« dies nicht schon übernimmt – einem Aufruf von »ldconfig«, steht die Bibliothek für alle Programme des Systems zur Verfügung, doch die Paketverwaltung weiß nichts davon.

Der Natur der Sache gemäß gilt dies sowohl für Debian- als auch für RPM-Systeme. Dennoch sind die Auswirkungen für die Praxis unter Debian/Ubuntu und unter Suse unterschiedlich. Jedes Paketmanagement-System wählt die Bibliothek XYZ zunächst automatisch aus, sobald eine zu installierende Software sie voraussetzt. Doch in Yast kann der Anwender unerfüllte Abhängigkeiten ignorieren und die gewünschte Software so installieren.

Das Umgehen der Paketverwaltung und mehr noch das Ignorieren von Abhängigkeiten ist ein zweischneidiges Schwert. Die Aufgabe, festzuhalten, dass und in welcher Version Bibliothek XYZ auf dem System installiert ist, kann die Paketverwaltung nicht mehr übernehmen, sie liegt jetzt in der Verantwortung des Anwenders. Die Debian-Policy ist es, ihm diese Verantwortung auch auf Wunsch nicht zu übertragen: Das Debian-Paketsystem quittiert den Dienst, wenn es auf einem System unerfüllte Abhängigkeiten gibt. Dann lassen sich auch keine Pakete mehr installieren, die die fehlenden Komponente gar nicht benötigten – eine unnötige Einschränkung. Die Smart-Entwickler betonen, dass ihr Paketmanager auch noch auf Systemen mit defekten Abhängigkeiten funktioniert [4].

Szenario 2

Der Anwender hat ein Softwarepaket heruntergeladen. Beim Installieren soll der Paketmanager die Abhängigkeiten für ihn auflösen. Bei modernen Distributionen genügt ein Mausklick: Unter Debian/Ubuntu startet Gdebi, unter Suse öffnet der Klick KRPMView, das eine Vorschau des Paketinhalts bietet. Ein weitere Klick auf den Button »Paket mit YaST installieren« öffnet das Yast-Modul. In beiden Fällen löst die Software Abhängigkeiten mit allen der Softwareverwaltung zur Verfügung stehenden Paketen.

Weniger Komfort bieten Debian- und Ubuntu-Systeme jedoch, wenn der Anwender mehrere Softwarepakete runtergeladen hat, die gegenseitig voneinander abhängen. Beim Start des Paketmanagers durch den Klick auf eine Deb- oder RPM-Datei beachtet die Paketmanagement-Software nur dieses eine Paket. Mehrere Pakete lassen sich unter Debian und Ubuntu nur in die Softwareverwaltung einbinden, wenn sie in einem Debian-Repository liegen. Ein solches zu erstellen ist zwar nicht besonders schwer [5], wenn es dabei aber nur um wenige Pakete geht, ist es dennoch lästig. Der Einsatz von »Dpkg« mit der Option »–force« erstpart dem Administrator zwar diesen Aufwand. Für eher unerfahrene Anwender ist dieser Weg jedoch nicht zu empfehlen.

Yast kennt einen Repository-Typ “lokales Verzeichnis”. Die Software analysiert bei jedem Start den Inhalt der darin liegenden Pakete. Wenn es nicht gleich Hunderte von Paketen sind, ist dies von der Performance her kein Problem.

»smart install Pfad zum Paket« oder »smart install URL« installiert einzelne Pakete auf der Festplatte oder aus dem Internet. Smart bindet außerdem wie Yast solche Pakete, die in einem einfachen Verzeichnis liegen, auch unter Debian ein – theoretisch zumindest. Im Test stürzte das Programm dabei unter Ubuntu 7.10 jedoch reproduzierbar ab, das Einbinden von RPMs unter Suse funktioniert aber. Smart befindet sich noch im Betastadium, die Entwickler warnen vor möglichen Bugs, was sich als begründet erweist.

Szenario 3

Beim Auflösen der Paketabhängigkeiten ist nicht nur geradliniges Denken gefragt. Abbildung 5 skizziert einen einfachen Test: Das Testpaket hängt von einem anderen Paket ab, das in den eingebundenen Repositories in zwei Versionen vorliegt. Die neuere lässt sich wegen einer eigenen unerfüllten Abhängigkeit nicht installieren, die ältere ist installierbar. Alles, was der Paketmanager nun tun müsste, wäre, die ältere Version zu wählen. Doch Apt und Synaptic kommen in der skizzierten Situation zu keinem entsprechenden Ergebnis.

Abbildung 5: Leicht in die Irre zu führen: Apt und Synaptic sind bereits bei einem einfachen Szenario überfordert, bei dem der Dependency-Solver die ältere Version einer Abhängigkeit wählen müsste, weil die neuere ihrerseite eine unerfüllte Abhängigkeit aufweist.

Erschwerend kommt noch hinzu, dass »apt-get« den Benutzer zusätzlich mit irreführenden Fehlermeldung verwirrt. Die ersten vier Zeilen weisen, in der deutschen Übersetzung schwer verständlich, darauf hin, dass nicht erfüllte Abhängigkeiten im Instable-Zweig von Debian häufiger vorkommen. Damit, dass Benutzer andere Repositories als die Debian-eigenen einbinden könnten, rechnen die Maintainer von Apt offenbar gar nicht. Weitere vier Zeilen informieren den Anwender darüber, dass, da er nur ein Paket angefordert hat, es wahrscheinlich dieses ist, das das Problem ausgelöst hat – bestechend einfache Logik, aber dennoch falsch: Das Problem tritt erst mit einem als Abhängigkeit automatisch gewählten Paket auf.

Ist der Anwender bereit, noch mehr als diese Zeilen zu lesen, sieht er die Meldung: »testpaket: Hängt ab: dependency-a soll aber nicht installiert werden«. Wahr ist, dass »dependency-a« sehr wohl installiert werden soll, es ist ja eine Abhängigkeit von »testpaket«. Dies gelingt nur nicht, da der Dependency-Solver die mögliche Auflösung nicht erkennt. Die abschließende Fehlermeldung »E: kaputte Pakete« ist ebenso irreführend. Ein Paket ist deswegen noch lange nicht kaputt, weil nicht alle Abhängigkeiten zur Verfügung stehen.

Kommunikationsproblem

Hätte Apt einfach mitgeteilt, dass sich die Abhängigkeit »dependency-a« wegen ihrerseits unerfüllter Abhängigkeiten nicht installieren lässt, hätte der Anwender eine Chance, die Situation mit »dpkg –force-all« per Hand zu lösen. Um aus der Ausgabe von Apt hingegen zu schließen, dass es sich schlicht um eine unerfüllte Abhängigkeit im automatisch gewählten Paket »dependency-a« handelt, ist viel Hintergrundwissen nötig.

Die grafische Apt-Alternative Synaptic verkürzt zwar die Apt-Meldung um die nicht sachdienlichen ersten acht Zeilen, die Meldung »Hängt ab: “dependency-a”, aber es wird nicht installiert« hilft allerdings wie bei Apt auf der Konsole nur Eingeweihten weiter.

Die Entwickler gaben Smart seinen Nahmen, weil dessen Dependency Solver ihrer Meinung cleverer ist als die der anderen Paketverwaltungs-Tools. Im Vergleich mit »apt-get« stimmt dies. Doch kommen außer Apt auch alle anderen Werkzeuge mit der vorgestellen einfachen Situation klar: Yast wählt wie Smart die ältere, aber installierbare Version.

Auch das Debian-Kommandozeilen-Tool Aptitude, das seit Debian 4.0 das in die Jahre gekommen Apt ersetzt, schafft dies. Zwar spricht es zunächst von unerfüllten Abhängigkeiten, macht aber einen Vorschlag, der den Konflikt löst. Akzeptiert der Benutzer die vorgeschlagene Lösung nicht mit [Y], so zeigt die Software die Alternativen.

Szenario 4

Beim Kompilieren tritt die Fehlermeldung »File xyz.h not found« auf. Das »configure«-Skript hat übersehen, dass die Headerdateien für eine zum Kompilieren nötige Bibliothek nicht installiert sind, sodass der Versuch fehlschlägt, gegen sie zu linken. Der nächste Schritt, damit das Übersetzen aus den Quellen doch noch gelingt, ist, herauszufinden, welches Paket die Datei »xyz.h« enthält. Die Debian-Paketverwaltung kennt jedoch nur den Inhalt der installierten Pakete. Um herauszufinden, welche Software er benötigt, muss der Anwender daher auf Internet-Suchmaschinen [6] zurückgreifen. Die Smart-Suchfunktion schließt weder die Inhalte installierter noch nicht installierter Pakete ein.

Nur Yast kennt bereits vor dem Einspielen auf das System den Inhalt aller Pakete in den eingebundenen Repositories (Abbildung 6). Nur unter Suse lässt sich also das Problem, welches im Moment nicht installierte Paket eine bestimmte Datei liefert, mit den Bordmitteln ohne Internetverbindung lösen.

Abbildung 6: Alleinstellungsmerkmal: Nur Yast bringt das Kunststück fertig, jenes Paket zu finden, das die Datei »libcairo_filter.so« enthält, obwohl es nicht installiert ist.

Außer nach enthalten Dateien (was dem RPM-Attribut Provides entspricht) sucht Yast auch noch nach dem RPM-Attribut Requires, also danach, welche anderen von einem bestimmten Paket abhängen. Diese Information sieht der Anwender jedoch auch, wenn er das Paket testweise für die Deinstallation auswählt. Nützlich ist, dass Yast anders als das grafische Debian-Werkzeug Synaptic die Größe nicht installierter Pakete anzeigt. »aptitude show Paketname« oder »apt-cache show Paketname« auf der Konsole fördert diese jedoch auch auf Debian-Systemen zu Tage.

Träges Schwergewicht

Als Kehrseite der vielen Informationen, die Yast zur Verfügung stellt, ergeben sich jedoch extrem lange Ladezeiten beim Updaten der eingebundenen Online-Paketrepositories: Das Einlesen des Open-Suse-Hauptrepository dauert unter Version 10.3 an einer etwa 300 KBit/s schnellen Leitung inklusive Erstellen des Cache über zwei Minuten. Apt braucht für das Einlesen des Ubuntu-Main-Repository nur wenige Sekunden.

Obwohl die Paketverwaltung mit Open Suse 10.3 spürbar schneller wurde, dauert es bei vielen eingebundenen Softwarequellen oft mehrere Minuten, bis die Softwareverwaltung startet. Eine Zumutung, die die Vorteile von Yast – wie die Fähigkeit, nicht installierte Pakete zu durchsuchen – stark relativiert.

Bleibt ein Repository seit dem letzten Update vollständig unverändert, lädt Yast die Daten dank Caching zwar nicht erneut aus dem Netz herunter, doch auch das Einlesen des Cache für ein Repository dauert etliche Sekunden.

Vor diesem Hintergrund ist unverständlich, warum der Benutzer nicht wenigsten wie bei Smart gezielt bei Bedarf Repositories updaten kann, ohne die Softwareverwaltung zu verlassen. Unter Yast stellt der Benutzer in einem gesonderten Modul für einzelne Repositories ein, ob Yast sie bei jedem Start des Paketmanagers updaten soll oder nicht.

Ist das Update für mehrere Repositories aktiv, so startet die Paketverwaltung oft erst nach minutenlangen Wartezeiten – sehr lästig, wenn der Anwender nur ein einzelnes Paket installieren möchte, das mit den Repositories, die Yast beim Start neu einliest, nichts zu tun hat.

Um einzelne Quellen bei Bedarf upzudaten, muss der Benutzer außerdem das »Software«-Modul von Yast beenden und eine andere Komponente starten, was besonders wegen der sowieso langen Startzeiten die Nerven des Anwenders gehörig strapaziert.

Szenario 5

Der Server eines oder mehrere Repositories sei als letzter Test überlastet. Bei der Verwaltung der eingebundenen Online-Repositories wird Smart seinem Namen gerecht: Es berücksichtigt auf Wunsch mehrere Mirrors eines Repository. Die Software weiß dann, dass es sich um das gleiche Repository handelt. Beim Updaten liest sie gespiegelte Repositories nur einmal ein und wählt dabei wie beim Herunterladen der Software den schnellsten Mirror. Nach Angaben der Entwickler merkt sich Smart sowohl langsame Mirrors als auch solche, deren Inhalte veraltet sind, und benutzt sie in Zukunft nicht mehr.

Da es, gerade wenn eine Distribution in einer neuen Version erscheint, recht häufig zu Überlastungen der Server kommt, spart die intelligente Mirror-Verwaltung in Smart viel Zeit. Hinzu kommt, dass Smart ohne Neustart auch gezielt einzelne Repositories aktualisiert. Die Software nimmt außerdem abgebrochene Downloads wieder auf. Für das Herunterladen der Dateien unterstützt Smart außer FTP und HTTP auch SCP, also den Download über SSH.

Fazit

Yast löst die Abhängigkeiten ordentlich auf und lässt dem Benutzer die Freiheit, Dependencies zu ignorieren, nervt aber durch seine schleppende Performance. Apt ist schnell, schlampt aber beim Auflösen der Abhängigkeiten. Dies gilt auch für Synaptic, das sich ansonsten als Musterbeispiel für einfache Bedienung gibt. Apt-Nachfolger Aptitude bringt mit der Kommandozeilen- und Ncurses-Oberfläche den Debian-Dependency-Check auf Augenhöhe mit denen von Yast und Smart. Smart integriert ein zeitsparendes Mirror-System und gibt sich in der Abhängigkeitsfrage intelligent, ist aber noch nicht stabil.