Paketverwaltung
Hintergrund
In der Frühzeit von Linux waren die .tgz-Pakete gängig; eine automatisierte Verwaltung war mit ihnen kaum möglich.
- Abhängigkeiten wurden weder aufgelöst, noch wurde zumindest eine Warnung ausgegeben.
- Anwender, die Software installieren wollten, mussten entweder genug wissen, um diese Abhängigkeiten selbst aufzulösen, oder installierten einfach alle Pakete, was aber wiederum die Gefahr von Paketkonflikten mit sich brachte.
Gewisse Ansätze einer Paketverwaltung gab es, als in Anlehnung an die großen Paketverwaltungen der etablierten Unix-Systeme dieser Zeit – wie SunOS (ein Vorläufer von Solaris), HP-UX, OSF/1, IRIX oder Apollo Domain/OS – erste Werkzeuge entwickelt wurden, die jedoch nur wenige Funktionen mitbrachten.
Dies verursachte den Linux-Distributoren dieser Zeit erhebliche Probleme beim Support und bei der Pflege ihrer Software, woraufhin zwei konkurrierende Systeme entwickelt wurden: das Debian-Paketmanagement dpkg für Debian-Pakete, initiiert vom Debian-Projekt, und RPM von Red Hat.
Das Ziel war es, Softwarepakete genauso für den Entwickler wie auch für den Anwender einfacher handhabbar zu machen, Abhängigkeiten sollten berücksichtigt und möglichst automatisch aufgelöst werden.
- Redundanzen wie doppelte Dateien oder Verzeichnisse sollte das System vermeiden, und es sollte möglich sein, Software sauber zu deinstallieren und dabei Abhängigkeiten zu beachten.
- Auch sollte es möglich werden, Software einfach zu aktualisieren und Konfigurationsdateien sicher zu verwalten.
Eine Funktion zur Rückabwicklung bei Fehlern (Transaktionen und Rollback) ist inzwischen ebenso Bestandteil von RPM wie bei den großen Paketverwaltungen von HP-UX und Solaris, wenn auch noch nicht in gleichem Umfang.
Portierungen
Eine Paketverwaltung ist systemabhängig.
- So besitzen außer verschiedenen Distributoren nicht mal alle Linuxanbieter das gleiche Paketformat.
- Andere Systeme bringen natürlich ihre eigene Software mit.
Da aber auf vielen anderen Unix-Systemen mittlerweile die GNU-Software zur Grundausstattung gehört (zumindest installiert der Systemverwalter sie in der Regel ganz schnell nach) wurde auch RPM – vor allem im Rahmen des Projektes OpenPKG – auf andere Systeme portiert, wodurch man einfach zusätzliche Software einspielen kann.
In gewissem Sinn ist dies gleichermaßen ein Fortschritt und ein Rückschritt.
- Bisher haben Systemverwalter aus den Quellen die Software selber kompiliert und dann in das System eingepflegt.
- Dieser Schritt und die damit angefallene Arbeit entfallen natürlich.
Allerdings gibt es zwischen der Paketdatenbank von RPM und der systemeigenen Paketdatenbank keine Kommunikation, und somit werden doppelte Installationen genauso wenig aufgelöst wie fehlende Systemabhängigkeiten über die Paketsysteme hinweg.
Für OS/2 bzw. ecomstation wurde das System auch portiert,[1] so dass es sich inzwischen nicht mehr nur auf unixartige Betriebssysteme beschränkt.