Paketmanagement – Grundlagen

Grundlagen

Paketformate

Für viele ist das Paketformat und die Paketverwaltung quasi identisch. Technisch gesehen ist das aber keineswegs so. Zum Einen gibt es das Paketformat, also das Dateiformat welches die Software-Daten und Metainformationen enthält, sowie die Software, welche dieses Format einliest und verwaltet. Zum Anderen existiert der Paketmanager, welcher für das Interpretieren der Paket-Metainformationen (Abhängigkeiten, Konflikte, etc.) und für diverse Hilfsaufgaben (z.B. Repositories, Updates) zuständig ist.

Ein Paketformat wäre z.B. RPM, die Paket-Verwaltung und das zugehörige Tool heißen ebenfalls RPM. Für RPM gibt es nun diverse Paketmanager, wie  z.B. die textbasierenden Werkzeuge Yum oder Zypper, oder auch grafische Werkzeuge wie YaST. Bei Debian hingegen wäre das Paketformat DEB/DPKG, der textbasierende Paketmanager jedoch APT und als grafisches Frontend wäre hier Synaptic zu nennen

Jedes Paketformat wurde für einen speziellen Einsatzzweck entwickelt und setzt andere Schwerpunkte. RPM und DEB als eine der ältesten Paketformate wurden als flexible Formate für den generellen Einsatz entwickelt. DEB hat dabei eine eigene Evolution durchgemacht, da Debian selbst als winzige Distribution mit nur einer handvoll Pakete und sehr einfach gestricktem Paketformat gestartet ist, und dann wesentlich größer wurde. Das DEB-Format wurde dabei leicht an die größeren Anforderungen angepasst. RPM kam seit Beginn an für größere Paketquellen zum Einsatz, hat sich aber ebenfalls verändert.

Warum wechselt jetzt nicht z.B. Debian zu RPM oder Fedora zu DEB? Die Gründe sind ziemlich pragmatisch: Es hat keinen Sinn und wäre kontraproduktiv. Der gesamte Workflow in Debian ist auf das DEB-Format ausgerichtet, alle Entwickler kommen damit klar, es funktioniert hervorragend und erfüllt alle Ansprüche. Gleiches gilt für RPM bei Fedora: Es hat schlicht keinen Sinn, zu wechseln. Der Nutzer hätte nichts davon, und für die Entwickler wäre es sinnloser Aufwand.

Zurück zur Übersicht

Paketverwaltungsbestandteile

Die zwei o.g. Paketverwaltungssysteme APT ( Advanced Packaging Tool ) und RPM  ( RPM Package Manager ) gliedern sich in folgende Teilprogramme auf, wobei jeder Bestandteil eine spezielle Funktion übernimmt.

dpkg-buildpackage ist ein Entwicklertool, es wird auf produktiven Systemen nicht verwendet und hat da eigentlich auch nichts zu suchen. Es verwendet völlig andere Parameter als das Pakettool und der Paketmanager, es macht also Sinn, dieses separat zu haben.

Das Pakettool ( dpkg / rpm ) verarbeitet lokale Pakete und abstrahiert die ganzen Details des Paketformates vom Paketmanager. Der Paketmanager muss nur noch das Pakettool aufrufen, um ein Paket zu installieren oder zu entfernen.

Der Paketmanager ( APT /Zypper,Yum ) hat den Überblick über die gesamte auf dem System installierte Software, sowie über verfügbare Software und deren Quellen. Er ist außerdem in der Lage, Abhängigkeiten zwischen Paketen aufzulösen und dem Pakettool genau zu sagen, welche Aktion wann aufgerufen werden muss um das System in einem konsistenten Zustand zu halten und alle Pakete sinnvoll zu installieren/zu entfernen.

Diese Aktionen sind hochspezialisiert und daher von einander getrennt. Der Paketmanager braucht keine genaue Kenntnis vom Paketformat, ebenso wenig, wie das Pakettool wissen muss, was gerade im gesamten Archiv passiert. Mit all dem überhaupt nichts zu tun hat das Paket-Entwicklerwerkzeug.

Zugegeben, ein Paket ist komplex – allerdings ist diese Komplexität oft essentiell. Und nahezu alle Dateien sind einfache Textdateien, die sowohl von Menschen gut gelesen werden können, als auch von Maschinen verarbeitet werden können. Paketmanager und Pakettool können in einer Anwendung zusammengefasst werden ( Arch Linux ), was aber in Bezug auf Flexibilität und Fehlersuche suboptimal ist.

Zurück zur Übersicht

PackageKit

PackageKit ist eine dritte Schicht über dem Pakettool und dem Paketmanager und stellt viele Aktionen der Paketverwaltung über eine Schnittstelle systemweit und unabhängig von den Paketverwaltungsbestandteilen zur Verfügung. Über diese Schnittstelle können Nutzer mit dem Paketmanagement einfach kommunizieren, wenn sie sich nicht mit der (nützlichen) Komplexität des Systems oder der Syntax der verschieden Paketverwaltungssysteme auseinandersetzen wollen. Somit sind folgende Befehle für Systeme auf denen Packekit installiert allgemein gültig :

• pkcon update => Aktualisierung des Paket-Zwischenspeichers
• pkcon upgrade => Aktualisierung des Systems
• pkcon search file /path/to/filename.txt => Auflisten eines Paketes, welches die besagte Datei enthält.

Zurück zur Übersicht

Komplexität

Das Paketmanagement einer Distribution ist mitunter unglaublich komplex. Das liegt aber nicht daran, dass die Programmierer das so gewollt haben, sondern viel mehr am komplexen Problem selber.

Alleine der Paketbauprozess muss mit ettlichen Buildsystemen für Software zurecht kommen, es müssen zig verschiedene Dateien an die richtigen Orte installiert kopiert und registriert werden. Zudem muss auf distributionsspezifische Eigenheiten eingegangen werden. Damit muss der Buildprozess sehr flexibel sein, was ihn automatisch komplizierter macht.

Das Pakettool hingegen muss seine Datenbank extrem schnell verwalten können, und muss zu jeder Zeit sicherstellen, dass diese konsistent ist, und nicht beschädigt wird.

Der Paketmanager wiederum muss die ganzen Paketpools verwalten, und Abhängigkeiten zwischen Paketen möglichst schnell auflösen. Dazu zählen nicht nur “Paket X braucht Paket Y”-Abhängigkeiten, sondern auch Konflikte eines Paketes mit einer Version eines anderen Paketes, oder vom Nutzer festgelegte Sperren eines Paketes (z.B. apt-pinning).

Zurück zur Übersicht

Fazit

Jeder Versuch, das Paketmanagement an sich zu vereinfachen wird auf Grund des Problems selber nicht funktionieren, oder nur unter Verlust vieler Funktionen und der “Robustheit” des Systems. Zudem ist jedes Paketmanagement quasi mit der Distribution “gewachsen”, es zu ersetzten würde also in jedem Fall erstmal zu mehr Bugs und Problemen führen. Um das zu tun, braucht man also schon einen triftigen Grund.

Was allerdings auch stimmt, ist dass der Zugang zum Paketmanagement unnötig kompliziert ist, vor allem für simplere Aufgaben. Auch noch so komplexe Dinge kann man hinter einer schönen GUI oder einem cleveren CLI-Tool verstecken. An dieser Stelle kann ich jedem das PackageKit tool pkcon empfehlen, welches alle allgemeinen Aktionen der Paketdatenbank abdecken sollte.

Zurück zur Übersicht