Naar inhoud springen

RPM Package Manager

Uit Wikipedia, de vrije encyclopedie
RPM
Logo
Ontwerper(s) Marc Ewing, Erik Troan, Red Hat
Uitgebracht 1997 (26 jaar)
Recentste versie 4.20.0 (7 oktober 2024)[1] Bewerken op Wikidata
Recentste bètaversie 4.20.0 BETA1 (24 juni 2024)[2] Bewerken op Wikidata
Status Actief
Besturingssysteem GNU/Linux, Unixachtig besturingssysteem
Geschreven in C
Categorie Beheer van software pakketten
Licentie(s) GPLv2
Versiebeheer Officiële broncode
Website Officiële website
Portaal  Portaalicoon   Informatica
Vrije software

RPM Package Manager (of RPM, oorspronkelijk Red Hat Package Manager genaamd) is een package manager die primair is bedoeld voor het besturingssysteem Linux. RPM installeert, update, verwijdert, verifieert en bevraagt softwarepakketten. RPM is het standaardsoftwarepakketformaat van de Linux Standard Base. RPM is oorspronkelijk ontwikkeld door Red Hat voor Red Hat Linux, maar wordt nu door vele Linuxdistributies gebruikt. Het is daarnaast ook geporteerd naar enkele andere besturingssystemen, zoals Novell Netware (sinds versie 6.5 SP3) en IBM AIX. De vorm waarin het acroniem "RPM" heden ten dage wordt gebruikt, i.e. in de betekenis "RPM Package Manager", is een goed voorbeeld van een recursief acroniem.

De RPM-database

[bewerken | brontekst bewerken]

Achter de schermen van RPM zit de op Berkeley DB gebaseerde RPM-database. Deze bevat alle informatie voor elk geïnstalleerd pakket. De database houdt de gegevens bij van elke file die door middel van RPM is geïnstalleerd. Daardoor kunnen diezelfde geïnstalleerde files eenvoudig weer worden verwijderd. Indien de database verstoord raakt, wat kan gebeuren indien het RPM-programma abrupt wordt afgebroken, kan de database vaak toch nog worden hersteld dankzij de ingebouwde dubbelgelinkte lijst. Op Red Hatsystemen staat de database in /var/lib/rpm. Een lijst met de bestanden in de database kan afgedrukt worden met de opdracht:

gebruiker@laptop ~ $ rpm -qc rpm
PackageKit

Door Linuxgebruikers en systeembeheerders worden rpm-bestanden gebruikt om op een eenvoudige manier software te kunnen updaten, upgraden of installeren. Het programma rpm vormt de basis van het pakketbeheersysteem. Daar overheen wordt meestal een gebruiksvriendelijke gebruikersomgeving (frontend), zoals yum of PackageKit, gebruikt waarmee een gebruiker via een simpele opdracht of een paar muisklikken, een toepassing kan installeren of updaten.

De volgende gereedschappen worden veel gebruikt op RPM-gebaseerde systemen:

Elk RPM-softwarepakket in een repository heeft een naam die bestaat uit een label of etiket en een extensie .rpm.

Het label bevat de volgende gegevens:

  • de pakketnaam
  • de versie van het pakket (een code die van het versiebeheersysteem van de oorspronkelijke softwarebron wordt overgenomen)
  • de release (het aantal keren dat een gelijkende versie van het pakket werd samengesteld); met dit veld wordt bovendien vaak de desbetreffende distributie waarvoor het bedoeld is, aangeduid, bijvoorbeeld door tekenreeksen als mdk (Mandriva Linux), fc4 (Fedora Core 4), rhl9 (Red Hat Linux 9), suse93 (SuSE Linux 9.3) etc.
  • de architectuur waarop of waarvoor het pakket werd gebouwd (i386, i686, Athlon, ppc, etc.)

De naam van elk RPM-softwarepakket heeft normaliter het volgende formaat:

<naam>-<versie>-<release>.<arch>.rpm

Een voorbeeld:

nano-0.98-2.i386.rpm

Het pakketlabel is vervat in de RPM-softwarepakketfile, maar stemt niet noodzakelijk overeen met de naam van de file.

Broncode wordt in SRPM-files verpakt en gedistribueerd. Zulke pakketten zijn bedoeld voor het maken van RPM-bestanden en behoren niet tot een bepaalde architectuur. Ze krijgen daarom als architectuurbenaming src (van het Engelse "source" = bron). Bijvoorbeeld:

libgnomeuimm2.0-2.0.0-3.src.rpm
Scripts
Naast software in de vorm van gecompileerde code wordt veel software geïnstalleerd in de vorm van een scripttaal voor een interpreter. Scripts zijn niet afhankelijk van de architectuur van de hardware. Op unixplatforms worden vaak shellscripts of scripts voor Perl en Python gebruikt. Een voorbeeld is yum:
yum-3.4.3-10.fc14.noarch.rpm
Het programma bestaat uit een script voor Python.
Libraries
Softwarebibliotheken (libraries) worden voor elke versie in twee afzonderlijke pakketten gedistribueerd. Het ene pakket bevat de voorgecompileerde code (de binary) die direct gebruikt kan worden en het andere (de library) bevat de ontwikkelingsfiles van het desbetreffende pakket, zoals zogenaamde headerfiles en de broncode van de implementatie. Aan de naam van deze librarypakketten is de tekenreeks -devel toegevoegd omdat deze pakketten alleen bestemd zijn voor softwareontwikkelaars. Om de library te laten samenwerken met andere programma's, dient de versie van de voorgecompileerde code overeen te stemmen met die van de library.
Documentatie en multimedia
Tot de noarch.rpm-categorie behoren verder beeld- en geluidsfiles en door andere programma's te gebruiken tekstinformatiefiles, zoals files met documentatie:
java-1.7.0-openjdk-javadoc-1.7.0.6-2.3.2.fc12.1.noarch.rpm
waarin de naam van het pakket java-1.7.0-openjdk-javadoc, de versie van het pakket 1.7.0.6 en de release van het pakket 2.3.2.fc12.1 is.

Voor- en nadelen van het RPM-systeem

[bewerken | brontekst bewerken]

Voordelen die vaak worden genoemd bij het gebruik van RPM-pakketten boven dat van andere manieren om software te verzamelen en te installeren, zijn:

  • Het installeren van programma's gebeurt steeds via dezelfde weg.
  • Het verwijderen van programma's is eenvoudig.
  • Populariteit: beschikbaarheid van veel pakketten, ook al dient er een hercompilatie plaats te vinden voor een andere distributie.
  • Niet-interactieve installatie: dit maakt het makkelijk om installatie te automatiseren.
  • Oorspronkelijke bronbestanden meegeleverd: dit maakt verificatie mogelijk.
  • Cryptografische verificatie met GPG of md5.
  • DeltaRPM's, die het RPM-equivalent zijn van patchfiles, zijn te combineren met reeds door RPM geïnstalleerde pakketten, waardoor updates kunnen worden uitgevoerd. Dit is een veel handiger manier om door RPM geïnstalleerde software te updaten, omdat DeltaRPM niet het oorspronkelijke RPM-pakket nodig heeft om de update uit te voeren.

Vaak genoemde nadelen zijn onder meer:

  • Er zitten soms (terugwaarts) incompatibele veranderingen in het pakketformaat.
  • De documentatie is incompleet en/of verouderd.
  • Het maken van RPM-pakketten heeft een steile leercurve.
  • Pakketversieafhankelijkheden spreken elkaar soms tegen, afhankelijk van de gebruikte Linuxdistributie.
  • "Gewone" programma's zijn niet in staat om RPM-pakketten uit te pakken, zoals mogelijk is bij tgz-files. Hierbij moet echter worden verteld dat de tarball van de broncode van het programma "rpm" een shellscript bevat - rpm2cpio.sh - dat in staat is om het "cpio"-archiefgedeelte van een RPM-file uit te pakken (door slechts gebruik te maken van "od", "expr", "dd" en "gunzip").

RPM is ook bekritiseerd voor het ontbreken van consistentie in pakketnamen en -inhoud, wat het automatisch afhandelen van afhankelijkheden kan bemoeilijken. Dit is echter geen probleem dat uniek is voor het RPM-systeem, omdat het een coördinatieprobleem betreft tussen de grote Linuxdistributies die RPM als pakketbeheersysteem gebruiken, zoals Red Hat Linux, SuSE en Mandriva Linux. Bij het gebruik van RPM-pakketten van een specifieke distributie (bijvoorbeeld Red Hat Linux) of van RPM-pakketten die zijn gebouwd voor een bepaalde distributie (bijvoorbeeld Freshrpms voor Red Hat Linux) kan een automatische afhankelijkhedenproef werken dankzij het gebruik van gereedschap als "yum" (Yellow Dog Updater Modified) of "apt" (Advanced Packaging Tool) (zie onder). Exclusief gereedschap voor Mandriva Linux is "urpmi", dat kan helpen bij de zogenaamde hel van afhankelijkheden.

Third-party software

[bewerken | brontekst bewerken]

Als een rpm-bestand van bepaalde software ontbreekt in de repositories van een Linuxdistributie, zoals dat bij propriëtaire software vaak het geval is, dan kan die software vaak als third-party software van de site van de leverancier gedownload worden. Als een leverancier een geschikt rpm-bestand aanbiedt, dan kan de software met dat bestand geïnstalleerd worden. Als een leverancier geen geschikt rpm-bestand kan leveren, dan kan de software eventueel vanaf een tarball opgebouwd worden.

Bijna alle Linuxdistributies met een RPM Package Manager zijn forks van Fedora, Mandriva of SUSE. Er zijn verschillen tussen de package managers van verschillende versies van deze distributies. Vaak worden van third-party software verschillende rpm-bestanden aangeboden voor verschillende Linuxdistributies, zoals Red Hat, Fedora, SUSE of Mandriva.

Pakketinformatie

[bewerken | brontekst bewerken]

Met de zoekfuncties van het RPM-programma kan informatie over een pakket online opgevraagd worden. Met de opdracht:

gebruiker@laptop ~ $ rpm -qpi <naam of url van rpm-bestand>

kan informatie over de inhoud en de herkomst van het rpm-bestand verkregen worden.

De opdracht:

gebruiker@laptop ~ $ rpm -qp --requires bestand.rpm

drukt een lijst met de versies van de pakketten af die op het systeem geïnstalleerd moeten zijn. Deze informatie kan van belang zijn voor de installatie van de software.

Het maken van RPM's

[bewerken | brontekst bewerken]

Het "recept" voor het maken van een RPM-pakket is een specfile. Namen van specfiles eindigen op ".spec" en deze files bevatten de pakketnaam, versie, RPM-revisienummer, de stappen om pakketten samen te stellen, te installeren en op te schonen, plus een changelog (= lijst van veranderingen). Uit een enkele RPM-specfile kunnen, indien gewenst, verscheidene pakketten worden samengesteld. RPM-pakketten worden gemaakt met behulp van "rpmbuild".

[bewerken | brontekst bewerken]
  • Eric Foster-Johnson, 2003: Red Hat RPM Guide (ISBN 0764549650), een complete, actuele handleiding voor het bouwen van RPM-pakketten. (Engelstalig)