RPM is het wijdst verbreide formaat voor pakketbeheer, en is door het Linux Standard Base (LSB) consortium tot standaard verkozen. We zullen er daarom wat dieper op ingaan dan strikt noodzakelijk is. Eerst komt de installatie van gewone binaire RPM pakketten aan de orde. Daarna wordt besproken hoe u met een RPM broncode pakket moet omgaan. Tot slot worden enkele uitbreidingen van het RPM systeem besproken.

 

Binaire RPM pakketten

Namen van RPM files zijn als volgt samengesteld:

pakketnaam-versie-uitgave.architectuur.rpm

Bijvoorbeeld:

athena-devel-2.4.3-87.i586.rpm

Hierin is athena-devel de naam van het pakket, 2.4.3 het versienummer en 87 het uitgavenummer. Het pakket is geschikt voor i586 (intel processor van de 586 familie: Pentium) en beter. Welke architectuur u hebt kunt u achterhalen door het programma arch te draaien, of uname met de optie -m (machine): uname -m. Op een 80486 kunt u geen i586 of i686 (Pentium IV en hoger) pakket installeren, maar wel een i386 pakket. Het is ook mogelijk dat een pakket voor elke architectuur geschikt is. In dat geval wordt noarch als aanduiding gebruikt, b.v.

athena-images-1.2-3.noarch.rpm

U installeert het voorbeeldpakket athena-devel met de opdracht

rpm -ivh athena-devel-2.4.3-87.i586.rpm

Opdracht -i staat voor "install", de optie v (voor "verbose") laat RPM veel informatie over het installatieproces geven, en de optie h (voor "hash symbols") zorgt voor een voortgangsbalkje zodat u kunt zien hoe ver RPM met installeren is gevorderd. Het is mogelijk dat RPM constateert dat niet aan de afhankelijkheden is voldaan, d.w.z. dat niet alle voor het pakket benodigde software is geïnstalleerd. Het geeft dan een lijst van ontbrekende pakketten. Dit kan twee dingen betekenen:

• De genoemde software is inderdaad niet beschikbaar
• De genoemde software is wel beschikbaar, maar niet met RPM geïnstalleerd, zodat het niet in de RPM database voorkomt.

In het laatste geval kan het pakket zonder problemen worden geïnstalleerd omdat alle benodigde software er is, ook al weet RPM dat niet. Om het pakket dan toch geïnstalleerd te krijgen moet de optie --nodeps (voer geen check op dependencies, afhankelijkheden, uit) worden gebruikt:

rpm -ivh --nodeps athena-devel-2.4.3-87.i586.rpm

Als een pakket met deze naam, maar eventueel een ander versie- en/of uitgavenummer, al op uw systeem staat zal RPM weigeren te installeren. Als het al aanwezige pakket een lager versienummer of - bij hetzelfde versienummer - een lager uitgavenummer heeft kunt u "upgraden" door de opdracht -U in plaats van -i te gebruiken:

rpm -Uvh athena-devel-2.4.3-87.i586.rpm

Wilt u een hoger versie en/of uitgavenummer overschrijven, dan zult u de optie --force moeten gebruiken:

rpm -Uvh --force athena-devel-2.4.3-87.i586.rpm

U kunt de upgrade opdracht -U ook gebruiken als het pakket nog niet op het systeem staat. Het zal dan worden geïnstalleerd alsof de installatie opdracht -i werd gebruikt.

Een pakket wordt gedeïnstalleerd met de -e (van "erase") opdracht, alleen gevolgd door de naam van het pakket:

rpm -e athena-devel

Er kan veel meer met RPM. Een uitgebreide handleiding voor het werken met RPM vindt u hier op http://www.redhat.com. Gebruikers van een op RPM gebaseerde distributie kunnen met het commando man rpm ook de rpm manual pages raadplegen.

RPM pakketten zijn in beginsel specifiek voor elke distributie. De belangrijkste verschillen hebben betrekking op de plaats in de directorystructuur waar de bestanden van het pakket worden neergezet, of waar andere bestanden verwacht worden te zijn. Gelukkig conformeren de belangrijkste distributies als Fedora, Mandriva en SUSE zich aan de Linux Standard Base (LSB). Naast ondermeer het feit dat het RPM formaat tot standaard is uitgeroepen, is ook de File System Hierarchy (FHS), ofwel de directorystructuur gestandaardiseerd. Niettemin kan de FHS soms op verschillende wijze worden geïnterpreteerd. Zo plaatst SUSE KDE en Gnome in speciale directories onder /opt, /opt/kde en /opt/gnome, terwijl Fedora en het van Redhat afgeleide Mandriva alle KDE en Gnome bestanden in de /usr structuur inbedden. Het gevolg is dan ook dat RPM pakketten van KDE en Gnome software voor SUSE niet onder Fedora of Mandriva zijn te gebruiken, en omgekeerd.

Andere verschillen hebben onder meer betrekking op opstartbestanden (init scripts) en de configuratie van systeemgebruikers. Ook de vereiste versie van de C library en van het RPM systeem kunnen verschillen, maar dat is niet zozeer een probleem tussen Linux distributies onderling maar tussen verschillende versies van Linux distributies in de tijd.

Niettemin zijn heel veel nieuwe RPM pakketten wel geschikt voor de nieuwere versies van de voornaamste distributies, ook al zijn ze voor een bepaalde distributie bedoeld. Er zou mogelijk een probleem kunnen zijn met afhankelijkheden als deze in de vorm van pakketnamen zijn gegeven. Naam en samenstelling van pakketten kunnen van distributie tot distributie namelijk verschillen. Als zeker is dat aan een bepaalde afhankelijkheid toch is voldaan kan het pakket dan altijd nog met de optie --nodeps worden geïnstalleerd. En mocht blijken dat het pakket toch niet werkt kan het altijd weer worden gedeïnstalleerd of vervangen door de bestaande wel werkende versie. In zo'n geval is het misschien een idee om de installatie te starten met een source rpm, of zelfs een source tarball. Deze kunnen immers voor een systeem passend worden gemaakt, en in het geval van de source tarball zijn er mogelijkheden om deze in het RPM systeem in te passen (met alien of checkinstall) ook al hoeft dat niet persé.

 

RPM broncodepakketten

Naast de binaire RPM pakketten met al gecompileerde software zijn er ook broncode pakketten, ook wel SRPM pakketten genoemd. Hun naamsextensie is .src.rpm. Het voordeel van het compileren van broncode op uw eigen systeem is dat het gecompileerde programma precies bij uw eigen systeem, zoals processor en aanwezige library versies, past.

Het bij ons voorbeeld behorende broncode pakket zou

athena-devel-2.4.3-87.src.rpm

heten. De architectuur aanduiding is voor broncode niet relevant en daarom vervangen door de aanduiding "src". De broncode wordt nu geïnstalleerd en vervolgens gecompileerd met de opdracht

rpm --rebuild athena-devel-2.4.3-87.src.rpm

t/m rpm versie 3, en met de opdracht

rpmbuild --rebuild athena-devel-2.4.3-87.src.rpm

vanaf rpm versie 4. Daarbij worden de broncode, de pakketspecificatie en het aangemaakte binaire RPM pakket in een speciale directorystructuur geplaatst. Normaliter is deze te vinden onder /usr/src/<package directory>, waarin <package directory> verschilt al naar gelang de distributie. Bij Fedora vinden we de RPM structuur onder /usr/src/redhat, bij SUSE onder /usr/src/packages, en bij Mandriva onder /usr/src/RPM. Hij bestaat uit de volgende directories:

• BUILD is de directory die RPM voor het bouwen van RPM pakketten gebruikt.

• SOURCES is de directory waarin de broncode en eventuele patches daarop worden geplaatst.

• SPECS is de directory waarin de RPM pakketspecificaties te vinden zijn. Zo'n pakketspecificatie maakt deel uit van het RPM broncodepakket en vormt de basis voor de samenstelling van het binaire RPM pakket.

• RPMS is de directory waarin de gecompileerde binaire RPM pakketten worden geplaatst. Elke architectuur (i386, i486, i586, i686, athlon, noarch) heeft hierin zijn eigen subdirectory.

• SRPMS is de directory voor de RPM pakketten met broncode.

Normaliter zal deze directorystructuur al bij installatie van het rpm pakket tijdens de installatie van de Linux distributie zijn opgezet. Zo niet, dan zult u hem eerst zelf moeten maken. U kunt indien gewenst een andere plaats voor de directorystructuur specificeren door in het configuratiebestand /etc/rpmrc naar deze plaats te verwijzen.

Na het compileren wordt automatisch een binair RPM pakket aangemaakt, dat u terugvindt in directory RPMS/<arch>, waarin <arch> staat voor de architectuur. Dit kunt u vervolgens op de gebruikelijke wijze installeren.

Indien gewenst kunt u de RPM pakketspecificatie voorafgaand aan de compilatie aan uw eigen wensen aanpassen. In dat geval moet u het broncode pakket op de normale wijze installeren:

rpm -ihv athena-devel-2.4.3-87.src.rpm

Vervolgens gaat u naar de SPECS directory en past u het specificatiebestand aan. Het kan bijvoorbeeld nuttig zijn om de directories te wijzigen waarin de bestanden van het binaire RPM pakket bij installatie worden geplaatst. Zo zou u een Fedora broncode pakket van een KDE programma geschikt kunnen maken voor installatie op een SUSE systeem. Nadat het specificatiebestand is aangepast kan het binaire RPM pakket worden gebouwd met de opdracht:

rpm -ba athena-devel-2.4.3-87.spec

t/m rpm versie 3, en met de opdracht

rpmbuild -ba athena-devel-2.4.3-87.spec

vanaf rpm versie 4. De opdracht -b staat voor "build", en met de optie a (voor "all") wordt aangegeven dat het hele bouwproces in één keer moet worden doorlopen.

 

Beheerssystemen voor RPM

In tegenstelling tot het Debian package management heeft RPM niet één universeel standaard beheerssysteem. Elk van de drie grote RPM distributies, SUSE, Mandriva en Fedora, heeft zijn eigen systeem ontwikkeld. Daarnaast is er bovendien Apt4rpm, het naar RPM geporteerde APT van Debian, dat geschikt is voor zowel SUSE, Mandriva als Fedora. Maar ook al is dat universeel, in geen van de drie distributies is het standaard en werkt het daarom niet "out-of-the-box". Hoewel er menugestuurde en/of grafische gebruiksomgevingen voor elk van de vier systemen zijn kunnen ze ook allemaal vanaf de opdrachtregel worden gestuurd. Alle vier halen te installeren software pakketten uit a priori opgegeven repositories, die op een voor elk systeem eigen wijze zijn ingericht. Ik stel ze hier voor:

• YaST is het universele beheerssysteem voor SUSE, dat onder meer over een module pakketbeheer beschikt. YaST heeft de beschikking over een GUI, een TUI (textual user interface) voor het console, en een CLI (command line interface) voor de opdrachtregel. Het artikel "Additional YaST Package Repositories" op de website van OpenSUSE geeft u een lijst van voor YaST beschikbare repositories. Een korte handleiding voor het toevoegen van repositories aan YaST vindt u in het artikel "Add Package Repositories to YaST".

  Blijkens "Install Software With YAST From the Command Line" en de help functie van yast (yast --help) gaat het installeren van software met de CLI als volgt:

  yast -i athena-devel-2.4.3-87.i586.rpm

  wordt het genoemde pakket geïnstalleerd. Hierbij draagt YaST er zorg voor dat aan alle afhankelijkheden wordt voldaan. Als niet alleen de naam van het pakket, maar zijn volledige pad wordt opgegeven zal YaST het pakket installeren zonder dat afhankelijkheden worden gecontroleerd. Het is ook mogelijk een pakket van een opgegeven repository te installeren door alleen de naam van het pakket te geven, bij voorbeeld:

  yast -i athena-images

  Ook in dit geval zorgt YaST dat aan alle afhankelijkheden wordt voldaan. Andere functies heeft de CLI niet.

  Naast Yast is er een Yast Shell voor Package Management voor het console, geheten y2pmsh. Deze moet apart worden geïnstalleerd. Het artikel "Software management met de Yast Shell" vertelt er meer over. Als y2pmsh wordt gestart worden eerst de Yast repositories ingelezen en indien gewenst ververst. Vervolgens kunnen binnen de shell allerlei opdrachten worden gegeven die met pakketbeheer hebben te maken. Zo kunnen met install en remove pakketten worden geselecteerd voor installatie dan wel verwijdering. Vervolgens worden worden de afhankelijkheden opgelost met solve en tenslotte alle nodige wijzigingen uitgevoerd met commit. Selecteren voor installatie, oplossen van afhankelijkheden en feitelijk installeren kan ook in één keer met de opdracht isc. Als u y2pmsh start zult u de mededeling "This tool is meant for debugging purpose only." zien, maar dat neemt niet weg dat hij goed werkt.

• Urpmi is het pakketbeheerssysteem van Mandriva. Net als bij de andere beheerssystemen moeten eerst de te gebruiken repositories aan het systeem kenbaar worden gemaakt. De simpelste manier om dat te doen is even naar Easy urpmi te surfen en het daar getoonde formulier in te vullen. Op basis daarvan genereert de site een commando dat u als root in een console moet laten uitvoeren. De locaties en andere benodigde gegevens van de gekozen repositories worden opgenomen in het configuratiebestand /etc/urpmi/urpmi.cfg. In plaats van Easy urpmi kunt u ook gebruik maken van de URPMI configuratie tool van MandrivaClub.NL, die ongeveer op dezelfde manier werkt.

  Nadat u alle te gebruiken software repositories hebt ingevuld moet u de opdracht

  urpmi.update -a

  geven om de lijst van beschikbare pakketten op te halen. Die lijst zal bijna dagelijks veranderen. Om de door urpmi gebruikte lijst weer met die van de repositories te synchroniseren geeft u ook deze update opdracht. Met behulp van cron zou u dat bij voorbeeld één maal per dag automatisch kunnen laten doen.

  Om een pakket uit één van de repositories te installeren, bijvoorbeeld het pakket met basisnaam athena-devel, geeft u de opdracht

  urpmi athena-devel

  Hierbij zorgt urpmi er voor dat ook alle pakketten waar athena-devel van afhankelijk is indien nodig worden geïnstalleerd. Als een oudere versie van het pakket al is geïnstalleerd zal het worden bijgewerkt. Installeren van een lokaal aanwezig, bijvoorbeeld zelf gedownload, RPM pakket is vrijwel net zo eenvoudig. Wel moeten dan de volledige naam en het pad er naar toe worden gegeven. Bijvoorbeeld een pakket in de actieve directory:

  urpmi ./athena-devel-2.4.3-87mdk.i586.rpm

  Urpmi zal dan aangeven welke extra pakketten eventueel nodig zijn om afhankelijkheden op te lossen en aanbieden ze te downloaden en te installeren. Als u dit accepteert zal het ook het gewenste RPM pakket installeren.
  Verwijderen van een pakket gaat met de opdracht

  urpme athena-devel

  Meer informatie over het werken met urpmi vindt u in Mandriva's RPM-HOWTO en op pagina SysAdmin/Urpmi van de Mandriva Community Wiki. Urpmi heeft een grafische interface met de naam RpmDrake. Mandriva's RPM-HOWTO geeft u ook daarvoor een handleiding.

• Yum is het pakketbeheerssysteem van Fedora. Yum betekent Yellow dog Updater, Modified. Het is oorspronkelijk ontwikkeld voor Yellow Dog, een Linux distributie voor de PowerPC. SUSE ondersteunt Yum ook sinds versie 10. De belangrijkste Yast repositories zijn geschikt gemaakt voor Yum.

  Ook yum werkt met speciaal voor yum aangepaste repositories. Het haalt de benodigde gegevens van die repositories, zoals de locatie in de vorm van een URL, uit het configuratiebestand /etc/yum.conf, of uit aparte configuratiebestanden per repository in directory /etc/yum.repos.d met een naam die eindigt op .repo. Bij installatie van yum zijn mogelijk al een of meer default repositories geconfigureerd. Een lijst van repositories voor Fedora vindt u hier op de wiki van Fedora-Linux.nl. U ziet daar ook in welke vorm u hun gegevens met behulp van een teksteditor aan yum.conf toe moet voegen.

  Een pakket uit één van de repositories, bijvoorbeeld het pakket met de basisnaam athena-devel, wordt geïnstalleerd door de opdracht

  yum install athena-devel

  te geven. Installeren van een lokaal aanwezig, bijvoorbeeld zelf gedownload, RPM pakket is vrijwel net zo eenvoudig. Wel moeten dan de volledige naam en het pad er naar toe worden gegeven. Bijvoorbeeld een pakket in de actieve directory:

  yum localinstall ./athena-devel-2.4.3-87mdk.i586.rpm

  Yum zal proberen afhankelijkheden met pakketten uit de geconfigureerde repositories op te lossen. Als dat niet lukt zult u zelf eerst de ontbrekende pakketten moeten downloaden en installeren.
  Een al geïnstalleerd pakket wordt bijgewerkt door het commando

  yum update athena-devel

  te geven. Verwijderen van een pakket gaat met de opdracht

  yum remove athena-devel

  Bij elkaar behorende pakketten kunnen kunnen als groep zijn georganiseerd. Stel dat er een groep "All of Athena" is, dan kunnen alle pakketten uit deze groep worden geïnstalleerd met de opdracht:

  yum groupinstall "All of Athena"

  Door groupupdate en groupremove in plaats van update en remove te gebruiken kan een groep worden bijgewerkt dan wel verwijderd.

  Handleidingen en HOW-TO's voor yum zijn er te over:

  • Korte Nederlandstalige handleiding op de wiki van de website Fedora-Linux.nl.
  • Kort Nederlandstalig artikel met de titel "Het gebruiken van Yum" op diezelfde website.
  • Engelstalige documentatie met de titel "Managing Software with yum" op de Fedora website.
  • Engelstalige HOW-TO op de Yum website.
  • Engelstalig artikel met de titel YUM: Yellowdog Updater, Modified eveneens op de Yum website.

  Er zijn verschillende grafische interfaces voor Yum:

  • Yum Extender is gebaseerd op de GTK interface en speciaal bedoeld voor Fedora Core. Het artikel "Yum Extender" op de wiki van de website Fedora-Linux.nl vertelt er meer over.
  • KYum is een grafische interface voor KDE.
  • GNOME interface for YUM is precies wat de naam zegt, een Yum interface voor Gnome ;-).

  In SUSE is KYum de standaard GUI, maar ook Yumex en de GNOME interface for YUM zijn beschikbaar via repositories van derden.

• Apt4rpm kan in zowel SUSE, Mandriva als Fedora worden gebruikt en werkt op dezelfde manier als APT. U zult het zelf moeten downloaden en installeren, maar dat is zeer zeker de moeite waard. Datzelfde geldt ook voor Synaptic, de bijbehorende GUI. Voor een flink aantal versies van de belangrijkste courante rpm distributies vindt u de juiste downloadlocaties van apt in de Apt-For-RPM-Howto. Ook Synaptic kunt u van de zelfde plekken downloaden als apt, met dien verstand dat Synaptic bij Fedora (en Redhat) in de directory synaptic in plaats van apt te vinden is.

  Om APT met vrucht te kunnen gebruiken moet het weten waar het de juiste software repositories voor uw distributie kan vinden. Alle configuratiebestanden van APT staan in de map /etc/apt. In /etc/apt/sources.list moeten de locaties van de verschillende software repositories worden ingevuld. U kunt sources.list zelf met een editor bewerken, maar u kunt het ook Synaptic laten doen door in het menu van Synaptic te kiezen voor Instellingen -> Pakketbronnen en in het dan verschijnende scherm de juiste gegevens in te vullen. SUSE en Fedora hebben speciaal voor APT ingerichte repositories. Dat geldt niet voor Mandriva, maar Apt4rpm ondersteunt Mandriva's urpmi repositories. In de Apt-For-RPM-Howto vindt u wat voor uw distributie de locaties van de belangrijkste software repositories zijn, en hoe u deze in /etc/apt/sources.list moet invullen. Elke regel van sources.list begint met een aanduiding van het type pakketten in de er na genoemde repository. Voor RPM zijn dat:

  rpm	rpm pakketten
  rpm-dir	rpm pakketten in lokale niet geindexeerde directorystructuur
  rpm-src	rpm pakketten met broncode
  rpm-src-dir	rpm pakketten met broncode in lokale directorystructuur

  Rpm-dir (en rpm-src-dir) zijn erg handig voor eigen gebruik. Stel dat u buiten de APT repositories om een aantal rpm pakketten hebt opgehaald, of misschien zelf rpm pakketten hebt gemaakt of geconverteerd, dan zijn deze eenvoudig in het APT systeem onder te brengen. Plaats daartoe de pakketten in een directory met bijvoorbeeld de naam

  /pad/naar/pakketten/voor/mijndistro/RPMS.eigen

  en voeg aan /etc/apt/sources.lst de regel

  rpm-dir /pad/naar/pakketten/voor/ mijndistro eigen

  toe. In de naam van de directory is alleen RPMS. verplicht. Wat daar achter staat is een groepsnaam die u zelf mag toekennen. U zou bijvoorbeeld een symbolische link RPMS.cdrom kunnen maken die verwijst naar een directory met rpm pakketten op een aangekoppelde cdrom. Er is één caveat bij dit systeem: het is mogelijk dat APT de afhankelijkheden voor de zo toegevoegde pakketten niet allemaal met de bekende repositories kan oplossen. In dat geval zult u zelf de ontbrekende afhankelijkheden aan uw verzameling pakketten moeten toevoegen.

  Nadat u alle te gebruiken software repositories, inclusief die van u zelf, hebt ingevuld moet u de opdracht

  apt-get update

  geven om de lijst van beschikbare pakketten op te halen. Die lijst zal bijna dagelijks veranderen. Om de door APT gebruikte lijst weer met die van de repositories te synchroniseren geeft u ook deze update opdracht. Met behulp van cron zou u dat bij voorbeeld één maal per dag automatisch kunnen laten doen.

  Om een pakket te installeren, bijvoorbeeld het pakket met basisnaam athena-devel, geeft u de opdracht

  apt-get install athena-devel

  Hierbij zorgt Apt4rpm er voor dat ook alle pakketten waar athena-devel van afhankelijk is zo nodig worden geïnstalleerd. Verwijderen gaat met de opdracht

  apt-get remove athena-devel

  Voor meer informatie en een uitgebreide handleiding kunt u terecht in de APT-HOWTO. Deze is geschreven voor Debian systemen, maar wat niet Debian specifiek is geldt ook voor Apt4rpm.

  Synaptic is weliswaar de belangrijkste GUI voor APT en Apt4rpm, maar er zijn er meer. Synaptic is gebaseerd op de GTK interface en past daarom beter bij Gnome dan bij KDE. Voor KDE is het aan Synaptic verwante Kynaptic beschikbaar, dat op de Qt interface is gebaseerd. Jammer is dat Kynaptic qua functies wat beperkter is dan Synaptic, en bovendien niet verder wordt ontwikkeld. Synaptic is overigens ook prima in KDE te gebruiken. Er zijn meer frontends voor APT, zowel in KDE als in Gnome, maar alleen Synaptic en Kynaptic werken ook met Apt4rpm. Naast de GUI's is er ook een tekstgeorienteerde interface (TUI) voor het console in de vorm van Aptitude, dat zowel voor APT als voor Apt4rpm beschikbaar is.