- RPM Package Manager
-
Dieser Artikel wurde im Portal Freie Software zur Verbesserung eingetragen. Hilf mit, ihn zu bearbeiten und beteilige dich an der Diskussion! RPM Package Manager 
Aktuelle Version 4.9.0
(2. März 2011)Betriebssystem Unixartige Systeme wie bspw. GNU/Linux Kategorie Paketverwaltung Lizenz GPL (Freie Software) Deutschsprachig Ja rpm.org RPM Package Manager ist ein freies (GPL) Software-Paketverwaltungssystem ursprünglich entwickelt von dem Unternehmen Red Hat. Es umfasst das Paketformat und alle nötigen Programme, um RPM-Pakete zu erstellen und verwalten.
Das RPM-Format ist Teil der Linux Standard Base und bedeutet RPM Package Management, ein rekursives Akronym.
Inhaltsverzeichnis
Hintergrund
In der Frühzeit von Linux waren die tgz-Pakete gang und gäbe; eine automatisierte Verwaltung war mit ihnen kaum möglich. Ein gezieltes Deinstallieren einzelner Pakete war nicht möglich. Auch wurden Abhängigkeiten 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.
Geschichte
Die erste Version von RPM basierte auf RPP, PMS (in den 1990er Jahren von Rik Faith für Linux-Betriebssysteme entwickelt) und PM und wurde in Perl geschrieben. Später wurde RPM in C neu geschrieben.
Ursprünglich bedeutete RPM Red Hat Package Management. Ende der Neunziger wurde der Name jedoch in RPM Package Management geändert. Der Hintergrund waren rechtliche Aspekte. RPM wurde inzwischen von vielen Distributoren verwendet, und man strebte die Aufnahme von RPM in die Linux Standard Base an. Der Unternehmensname (Firma) im Namen der Software hätte dies zumindest erschwert.
Zwischen 1999 und 2006 kam die Weiterentwicklung der Software praktisch zum Erliegen. Jeff Johnson, der Hauptentwickler von RPM bei Red Hat bis 1999, entwickelte jedoch die Software teilweise weiter und kümmerte sich um Fehlerkorrekturen. Aus diesem Zweig entstand RPM5 als Weiterentwicklung von RPM der Version 4.[1]
Die verschiedenen Distributoren entwickelten in der Zwischenzeit (1999–2006) eigene Patches für RPM, um Fehler zu beseitigen; Johnsons Patches wurden meist nicht verwendet.
Im Dezember 2006 schlossen sich verschiedene Distributoren unter Red Hat und Novell zum RPM-Projekt zusammen und entwickelten RPM mit den jeweiligen distributionseigenen Patches – weiterhin ohne Johnsons Änderungen – gemeinsam weiter.[2]
Daraus resultieren nun zwei Versionen von RPM: RPM mit Patches der Distributoren und RPM5, welches sich als RPM aus der „originalen Codebasis“ bezeichnet.[3]
Da die meisten Linux-Distributionen freie Software sind, besteht der Vorteil einer bestimmten Distribution gegenüber anderen zu einem großen Teil aus den Annehmlichkeiten des jeweiligen Paket-Managers (und aus den zusammengestellten, getesteten und regelmäßig aktualisierten (RPM-)Paketsammlungen des jeweiligen Distributors im Internet). Pakete zwischen Distributoren auszutauschen, war früher nahezu unmöglich. Dies wurde mit RPM einfacher, ist aber immer noch mit Problemen behaftet, da die verschiedenen Distributionen, die RPM benutzen, oft verschiedene Versionen und/oder Konfigurationen von Systemsoftware wie etwa Grafik-Bibliotheken verwenden.
Für den Entwickler vereinfacht ein Paketverwaltungssystem wie RPM das Einbauen von Software in die durch die Distribution vorgegebene Struktur (Pfade, Abhängigkeiten, Dateinamen, Paketnamen). Das Paketformat selbst überprüft allerdings den jeweiligen Inhalt eines Pakets nicht automatisch. Der Entwickler bestimmt den Aufbau des Paketes selbständig und muss sich damit für jede Distribution in die jeweiligen Besonderheiten einarbeiten.
Mit Einführung der Linux Standard Base wurden viele Unstimmigkeiten zwischen den Distributoren ausgeräumt. LSB erleichtert die Arbeit der Paketbauer erheblich, weil zumindest Dateinamen und Pfade vereinheitlicht sind. Entsprechende Sorgfalt des Paketmaintainers vorausgesetzt, lässt sich relativ sicher ein RPM von einem anderen LSB-Distributor in ein beliebiges anderes LSB-System einspielen.
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 OpenPKG Projektes – 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.
Siehe auch
- Paketverwaltung
- dpkg und .deb – das System bei Debian
- Ebuild und emerge – die Wahl bei Gentoo Linux
- Pacman – Paketmanager von Arch Linux
- Linux Distributionen
Weblinks
- Projektseite von rpm.org (englisch)
- Projektseite von rpm5.org (englisch)
- APT-RPM (englisch)
- Links zum Thema RPM im Open Directory Project
- RPM E-Book von Thomas Schletter
Einzelnachweise
Kategorien:- Freie Datenkompressionssoftware
- Freie Installationssoftware
- Linux-Software
- Datenformat
Wikimedia Foundation.
