Open Source im professionellen Einsatz

© photocase.com

Paketverwaltung mit Smart Package Manager

Smarte Gala auf der Treppe

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.

Diesen Artikel als PDF kaufen

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook