rpm ist ein Paketverwaltungs-System für Linux

Beschreibung

RPM Package Manager ist ein freies (GPL) Paketverwaltungs-System, ursprünglich entwickelt von dem Unternehmen Red Hat. Es umfasst das Paketformat und alle nötigen Programme, um RPM-Pakete zu erstellen und zu verwalten.

Das RPM-Format ist Teil der Linux Standard Base und bedeutet RPM Package Manager, früher Red Hat Package Manager.

Installation

Anwendungen

Fehlerbehebung

Syntax

Optionen

Parameter

Umgebungsvariablen

Exit-Status

Konfiguration

Dateien

Sicherheit

Dokumentation

RFC

Man-Pages

Info-Pages

Siehe auch

Links

Projekt-Homepage

Weblinks

Einzelnachweise

Testfragen

Wikipedia

Hintergrund

Paketverwaltung

In der Frühzeit von Linux waren die .tgz-Pakete gang und gäbe; 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.

Geschichte

Die erste 1995 für Red Hat Linux 2.0^[1] entwickelte Version von RPM basierte auf RPP, PMS (in den 1990er Jahren von Rik Faith für Linux-Betriebssysteme entwickelt) und PM; sie 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.

RPM wurde von zahlreichen Linux-Distributionen, wie z. B. SUSE, Mageia oder Mandriva Linux übernommen. Auch einige Unix-Systeme wie z. B. IBM AIX oder Solaris sowie nicht-unixoide Systeme wie Novell Netware nutzten RPM.

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.^[2]

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.^[3]

Daraus resultieren nun zwei Versionen von RPM: RPM mit Patches der Distributoren und RPM5, welches sich als RPM aus der „originalen Codebasis“ bezeichnet.^[4]

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 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,^[5] so dass es sich inzwischen nicht mehr nur auf unixartige Betriebssysteme beschränkt.

Aufbau

Die RPM-Dateien sind in der Regel mit gzip oder LZMA^[6] (xz) komprimierte cpio-Archive, die einzelnen Teile können jedoch einfach nach bestimmten Informationen durchsucht werden, denn ein Kopfdatenbereich im Binärformat ist an jedes Paket angefügt. Diese Kopfdaten sind nicht komprimiert und enthalten alle wichtigen Informationen. Das erleichtert das schnelle Durchsuchen von RPM-Paketen.

Entpacken ohne Installation ist möglich: rpm2cpio foo.rpm | cpio -idmv

XML Package Metadata

In den RPM-Spezifikationen finden sich ebenfalls die Spezifikationen für Verzeichnisse mehrerer RPM-Pakete. Die Pakete werden dabei in einem Verzeichnis gespeichert, das neben den Paketen noch Informationen über die Pakete selbst in Form von Metadaten-Dateien enthält. Wenn ein geeignetes Programm dann Informationen über die im Verzeichnis enthaltene Software benötigt, reicht es, die Metadaten herunterzuladen. In diesen Daten sind die vorhandenen Pakete, deren Versionen, Abhängigkeiten, Architektur etc. enthalten.

Programme, die XML-Package-Metadaten verwalten können, sind yum, Yast, Red Carpet, smartpm und apt-rpm.

Programme, die RPM-Pakete verarbeiten

• rpm – ein Linux-Programm, das direkt über die Konsole aufrufbar ist.
• Konsolen-Frontends
  • urpm von Mandriva – damit werden bei der Installation automatisch die Abhängigkeiten aufgelöst.
  • up2date von Red Hat
  • Yellowdog Updater, Modified (Yum)
  • YaST von SuSE – enthält ein Modul zur Verwaltung von RPMs
  • Smart Package Manager – dieses Werkzeug greift auf bestehende Werkzeuge (rpm, dpkg, … ) zurück und kann so auf vielen Distributionen eine einheitliche Oberfläche bieten
  • DNF
  • rpm-ostree – Tool aus Red Hats Container-Betriebssystem Atomic Host
• GUI-Frontends
  • KPackage (KDE)
  • gnorpm (Gnome)
  • Yumex und KYum – zwei grafische Oberflächen für Yum (Gnome; KDE)
  • PackageKit – ein grafisches Programm, das sowohl auf der Basis von APT als auch auf Yum läuft.
  • anpm (ArcaNoaePackageManager) – Frontend für OS2 bzw. eComStation.^[7]
• Maintaining Tools
  • apt4rpm – eine Portierung von APT für das RPM-Format.
  • rpmlint
  • alien – ein Programm, welches RPM-Pakete in Debian-Pakete für Debian (und auf dessen Paketverwaltung aufbauende Distributionen wie Ubuntu), und umgekehrt, konvertiert.
• Server / Repositories
  • RHN
  • Spacewalk – rpm repository channel tool
  • openSUSE Build Service
  • Pulp – rpm repository channel tool wie Spacewalk

Betriebssysteme, die RPM nutzen

Linux-Distributionen:

• AlmaLinux
• CentOS
• Fedora Project
• Mageia
• Mandriva Linux (nutzt einen Fork)
• MeeGo
• openSUSE
• Oracle Linux
• PCLinuxOS
• Red Hat Enterprise Linux
• Sailfish OS
• Scientific Linux
• SUSE Linux Enterprise (SUSE Linux Enterprise Server)

UNIX-Systeme:

• AIX
• Solaris

Andere:

• OS/2 / eComStation / ArcaOS
• Netware

Siehe auch

• dpkg und .deb – das System bei Debian
• Ebuild und emerge – die Wahl bei Gentoo Linux
• Pacman – Paketmanager von Arch Linux

Weblinks

• Projektseite von rpm.org (englisch)
• Projektseite von rpm5.org (englisch)
• APT-RPM (englisch)
• Vorlage:Dmoz
• Vorlage:Webarchiv von Thomas Schletter