Die üblichen Paketmanager wie Yum, Apt oder RPM werfen allen in die Abhängigkeiten-Hölle Geratenen bestenfalls Strickleitern zu. Das weitgehend distributionsunabhängige Smart-System errichtet den Verdammten dagegen eine Galatreppe.

Keine Frage: Paket-Management [1] soll in erster Linie nur gut funktionieren. Wer aber von den Standard-Installationsumfängen erwähnenswert abweicht oder seine Distribution in ein kleines Versionschaos stürzt – was ja eigentlich erlaubt ist – gerät schnell in die Dependency Hell [2], verstrickt sein Linux-System also in übermenschliche Abhängigkeitswirrungen. Hier will der Smart Package Manager [3], kurz Smart oder Smart PM einhaken.

Es handelt sich im Kern um ein modulares, vom vorgegebenen Paketmanagement unabhängiges Werkzeug. Zwar baut das Tool wie die Konkurrenzprogramme jeweils auf den distributionsabhängigen Formaten und Mechanismen auf. Es braucht sie aber im Gegensatz zu diesen Konfigurationen nicht zu ändern.

Smart löst die Paketabhängigkeiten mit eigenen Algorithmen auf. Die Distributionskomponenten Paketmanagementkern, Konfliktlösungslogik, Kommandozeilen-Interface und die grafische Benutzeroberfläche bleiben unangetastet. Stattdessen bietet Smart eine einheitliche Oberfläche zur Softwareverwaltung, bei Bedarf über viele Distributionen hinweg.

Total abhängig

Dadurch unterscheidet sich Smart von den anderen Werkzeugen und Frontends. Denn diese kommen entweder mit den Paketmanagement-Systemen der Distributionen ins Haus oder hängen von deren Paketmanagement ab. Das gilt für das Advanced Packaging Tool Apt [4] (für DPKG, [5]) im gleichen Maße wie für Apt-RPM [6], URPMI [7] für Mandriva, Red Hat und Fedora Yum [8] und Suses Software-Verwaltungskomponente von Yast 2 [9].

Diese Programme dienen lediglich als Benutzerschnittstellen. Denn sie delegieren die eigentlichen Operationen wie Installation, Löschen und Aktualisierung nur an das jeweilige Paketmanagement. Problematisch erscheint zudem, dass sich die Frontends deutlich voneinander unterscheiden, beispielweise:

• bei der Benutzeroberfläche,
• bei Fähigkeiten wie der Verwendung von Spiegel-Servern
  (Mirrors, [10]),
• beim Laden oder Vergeben von unterschiedlichen Prioritäten
  für manche Installationsquellen und
• bei den unterstützten Metadatenformaten der diversen
  Repositories. Ursache sind jeweils eigene Algorithmen zum Verwalten
  der Paketabhängigkeiten und zum Lösen der Konflikte.

Die Unterschiede bewirken, dass manche Distributionen über bessere Paketmanagement-Frontends verfügen als andere. Außerdem müssen sich Benutzer bei jeder neuen Distribution an die Fähigkeiten, Eigenheiten und die Bedienung des jeweiligen Frontends gewöhnen.

Smart adressiert das Problem. Die Software, die unter der GPL-Lizenz steht und in Python – wenige Performance-kritische Module auch in C – implementiert ist, zeichnet sich durch ihr modulares Design und Unabhängigkeit von jeder Implementierung eines Paketmanagement-Systems und von Repository-Formaten aus. Konkret unterstützt Smart zurzeit neben lokalen RPM- und Deb-Paketverwaltungen die Repositories Apt-Deb, Apt-RPM, Yum (RPM-MD), URPMI, Red Carpet [11], RPM Header List und Slackware. Weitere Management-Systeme sowie Repository-Formate lassen sich ohne weiteres verwenden, zum Beispiel das von Yast.

Universales Werkzeug

Tatsächlich besteht mit Smart eine realistische Möglichkeit, das Programm als einziges Paketverwaltungs-Frontend für alle RPM- und Deb-basierten Distributionen zu nutzen. Technisch könnten die meisten Hersteller und Projekte ihre Frontends wie Yast oder Up2date (Red-Hat- und Fedora-Mirror) auf den Smart-Kern portieren. Doch die Wahrscheinlichkeit, dass dies in naher Zukunft passiert, ist ziemlich gering. Allerdings plant wohl zumindest Mandriva, das hauseigene URPMI zu Gunsten von Smart aufzugeben.

Für einen Einsatz sprechen neben seiner Format- und Distributionsunabhängigkeit weitere Gründe: Smart besticht durch ein ausgefeiltes Transaktionsverfahren, das Paketabhängigkeiten und -konflikte löst. Dazu trägt wesentlich die Vergabe von Prioritäten und Sperren (Locks) bei. Diese darf der Benutzer pro Kanal und Paket vergeben und somit als unerwünscht, unveränderbar oder als bevorzugt klassifizieren. Zudem ist es möglich, die verfügbaren Szenarien mit Operationen zu kennzeichnen, etwa Installieren, Löschen und Aktualisieren.

Einstellungssache

Die Einstellungen trägt der Admin nicht wie bei vielen anderen Programmen in eine Textdatei ein, sondern nimmt sie am Tool selbst vor. Smart speichert seine Konfiguration dann in »/var/lib/smart/config«, einem über das Modul »cPickle« serialisierten Python-Objekt. Dauerhafte Einstellungen lassen sich über »smart config« vornehmen, nur für einen einzigen Lauf gültige mit dem Parameter »-o« respektive »–option« (siehe Tabelle 1).

Pakete kommen über Channels herein

Installationsquellen für die Pakete heißen bei Smart Channel (Kanal). Zu identifizieren sind sie durch Alias-Namen, frei wählbare, symbolische und innerhalb der Smart-Konfiguration eindeutige Bezeichnungen. Ein Channel informiert über die jeweiligen Repositories. Diese Metadatenverzeichnisse wiederum liefern die Information, von wo die Pakete beziehbar sind. Smart erlaubt derzeit die Formate Apt-Deb, Apt-RPM, RPM-MD, Red Carpet, URPMI und Up2date [12], siehe Beispiele in Listing 1.

Seit Version 0.40 zieht Smart auch die lokale Paketdatenbank (Deb-Sys, RPM-Sys oder Slack-Sys) als Channel heran. Aus Zeile 13 von Listing 1 ist ersichtlich, dass auch lokale Verzeichnisse als Kanal taugen. Smart besitzt aber zudem noch eine Logik zum Verwalten von Wechseldatenträgern. Es besitzt dazu eine Mountpoint-Autodetection, unterstützt Mehrfachmedien, und zwar in beliebiger Reihenfolge.

01 # Beispiel für das Hinzufügen eines Channels im APT-RPM-Format:
02 smart channel --add suse-10.0 type=apt-rpm name="SUSE 10.0" baseurl=http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.0-i386 components="base update security java"
03 #
04 # Ein APT-Repository für Ubuntu:
05 smart channel --add alias=breezy type=apt-deb distribution=breezy baseurl=http://de.archive.ubuntu.com/ubuntu components="main restricted"
06 #
07 # Der folgende Befehl fügt einen Channel im RPM-MD-Format hinzu und legt dessen Priorität fest:
08 smart channel --add suse-10.0 type=rpm-md name="SUSE 10.0" priority=10 baseurl=http://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse
09 #
10 # Kanalinformationen lassen sich nachträglich überschreiben:
11 smart channel --set suse-10.0 priority=100
12 #
13 # Die simpelste Channel-Variante greift ohne Repository in ein lokales Verzeichnis mit Paket-Dateien:
14 smart channel --add my-rpms type=rpm-dir name="Verzeichnis mit RPMs" path=$HOME/download/rpms

Prioritäten setzen

Die Möglichkeit, Prioritäten zu vergeben, hilft bei der Auflösung von Abhängigkeiten und Konflikten, zum Beispiel wenn mehrere Kanäle genau das gleiche Paket anbieten. Dann bestimmt Smart den Kanal zum Lieferanten, der den höchsten Rang hat. Die Vergabe von Prioritäten erfolgt durch Zahlen (Zeilen 8 und 11 in Listing 1). Je höher der numerische Wert liegt, desto bevorzugter die Behandlung – Apt-Anwender kennen das.

Üblicherweise ist der Kanal mit den Originalpaketen aus der Distribution mit der höchsten Zahl versehen. Doch es sind nicht ausschließlich positive Werte erlaubt, sondern auch negative. Falls der Administrator beim Anlegen eines Kanals keine Priorität angibt, bleibt es bei der Standardeinstellung »0«. Prioritäten können sich auch auf einzelne Paketnamen, sogar auf Paketnamen innerhalb eines Kanals beziehen. Dadurch lässt sich die Paketverwaltung noch spezifischer dirigieren – eher eine Spielwiese für erfahrene Benutzer.

Drei Schnittstellen zum Benutzer

Smart ist recht modular konzipiert. So wundert es nicht, dass auch die Bedienoberflächen komponentenbasiert sind. Augenblicklich präsentiert Smart seine Dienste über folgende Interfaces:

• die Kommandozeile, zum Beispiel »smart install
  apache2«,
• die Shell »smart –shell« und
• die grafische Oberfläche »smart –gui« (siehe
  Abbildung 1).

Abbildung 1: Smart erfreut GUI-Liebhaber mit einem gleichnamigen Frontend. Es ist funktional nicht kastriert, wie so häufig anderswo. Ähnlichkeiten mit der Benutzeroberfläche von Synaptic lassen sich nicht leugnen.

Die Shell verhält sich ähnlich wie die Oberflächen »apt-shell« und »y2pmsh«. Beim Aufruf der Shell-Variante liest Smart zuerst die systemweite Paketdatenbank und dann den Cache. In dem Cache stehen Informationen über die vorhandenen Pakete in den konfigurierten Channels. Der Ladevorgang kann einige Sekunden in Anspruch nehmen, je nach Leistung des Systems und der Anzahl der Pakete in den Kanälen. Anschließend bietet Smart dem Benutzer eine Bash-ähnliche Eingabe, inklusive Historie und [Tab]-Completion.

Die Shell kennt etliche Befehle. So kann der Bediener wie bei »y2pmsh« mehrere Schreiboperationen zum Installieren, Entfernen und Aktualisieren von Paketen absetzen und sie anschließend mit dem Befehl »commit« gesammelt ausführen. Die Konfiguration von Spiegelservern, Kanälen und Smart-spezifischen Einstellungen bleibt Smart-Shell-Benutzern allerdings versagt.

Abbildung 1 lässt erkennen, dass Smarts grafische Bedienungsoberfläche der bekannten Apt-Oberfläche Synaptic [14] ähnelt. Das Smart-Interface verwendet das Gimp-Toolkit GTK 2 [13]. Darum muss auf dem System ein Pygtk2-Paket installieren sein, bei Suse Linux Python-GTK 2.4. Wie bei dem Shell-Interface lädt das GUI den Cache nur einmal. Jedoch ist hier die Konfiguration von Kanälen und Spiegelservern möglich.

Alle drei Benutzerschnittstellen erlauben auch jenen Anwendern Lesezugriffe, die in dem Standard-Paketmanagement-System wenig Rechte haben. Sie können nach Paketen mit »smart search Suchbegriff« suchen, den Stand der installierten Pakete und verfügbaren Aktualisierungen mit »smart stats« anzeigen sowie weitere Informationen über Pakete abfragen mit »smart info Paketname«. Ganz praktisch kann es auch sein, die drei Interface-Arten zu kombinieren. Das geht, wie das zulässige Kommando »smart –gui install kdegames« beweist.

Einfach mit ranhängen: Spiegelserver verwalten

Im Gegensatz zu manch anderen Frontends ist es Smart leicht beizubringen, Spiegelserver zum Beziehen von Paketdateien zu verwenden. Der Benutzer braucht nur weitere URLs als Spiegel an eine Kanal-URL anhängen. Das funktioniert sogar über unterschiedliche Netzprotokolle hinweg (Listing 2).

01 smart channel --add suse-10.0 type=apt-rpm name="SUSE 10.0" baseurl=http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.0-i386 components="base update security java"
02 smart mirror --add ftp://ftp.gwdg.de/pub/linux/suse/apt http://ftp.gwdg.de/pub/linux/suse/apt
03 smart mirror --add ftp://ftp.gwdg.de/pub/linux/suse/apt ftp://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/apt

Sobald eine Verbindung über die primäre Kanal-URL oder den Mirror fehlschlägt, wechselt Smart automatisch auf den nächsten Spiegelserver. Ein solcher Fall tritt etwa durch ein TCP-Timeout ein, zum Beispiel weil gerade keine FTP-Session verfügbar oder eine Paketdatei unauffindbar ist.

Smart merkt sich die Versuche und die fehlerbehafteten URLs. Es entsteht eine Statistik. Diese beinhaltet außer den verwendeten URLs auch die jeweilige durchschnittliche Download-Geschwindigkeit. Smarts nachfolgende Operationen benutzen diese Informationen dazu, den schnellsten und zuverlässigsten Server auszusuchen. Bei miesem Datendurchsatz den Server zu wechseln ist aber noch nicht möglich.

Pakete und Protokolle

Smart kann unabhängig von den Möglichkeiten des zugrunde liegenden Paketmanagement-Systems die Pakete über unterschiedliche Protokolle laden: FTP, HTTP, HTTPS und SCP. Wenn Pycurl, die Python-Anbindung an die Curl-Bibliothek [15], installiert ist, kommen noch FTPS, Telnet, Dict und LDAP hinzu. Die Verfügbarkeit von Pycurl prüft Smart übrigens zur Laufzeit.

Außerdem lassen sich mit Hilfe von Smart mehrere Pakete gleichzeitig laden. Die Anzahl paralleler Downloads sowie eine in Sekunden gemessene Begrenzung für die Timeout-Funktion sind einstellbar:

smart config --set max-active-downloads=4
smart config --set socket-timeout=30

Das Beispiel begrenzt die Anzahl der gleichzeitigen Downloads auf vier und den Timeout bei Netzwerk-Operationen auf maximal 30 Sekunden.

Wo viel Licht ist

Insbesondere auf RPM-basierten Distributionen steht Smart Konkurrenz-Projekten nicht nach. Im Gegenteil: Das modulare und unabhängige Paketmanagement-Frontent überbietet offenbar in vielerlei Hinsicht Apt-RPM und Yum. Dennoch tropft auch bei Smart der Wermut ein paarmal hinein. So lädt und installiert die Software noch keine Quellpakete. Dazu kommt, dass Anwender, die DPKG einsetzen, die Fähigkeiten ihres Paketmanagement-Systems nicht mehr ausreizen können. So bindet sich Smart zwar an »debconf«, DPKG-Operationen wie »purge« funktionieren aber nicht. Außerdem übergibt Smart beim Löschen von Paketen den Parameter »–force-depends«, der umgeht aber Integritätsprüfungen der DPKG-Datenbank.

Schließlich fällt Smart durch Heißhunger beim Speicher auf, den nur der Administrator mit dem Befehl »disk-cache« etwas zu bremsen vermag. Hintergrund: Smart lädt normalerweise die Paket- und Kanal-Metadaten vollständig in den Hauptspeicher. Dadurch rechnet Smart seine Strategien auf gut bestückten Maschinen entsprechend zügig. Besitzern von Rechnern mit wenig Speicher verlangt die Software umso mehr Geduld ab. Aber trotzdem: Smart ist eine Empfehlung wert. (U. Ostler, jk)