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.
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 openSUSE, Fedora en Mandriva 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 openSUSE 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 openSUSE 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é.
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 openSUSE 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 openSUSE 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.
In tegenstelling tot het Debian package management heeft RPM niet één universeel standaard beheerssysteem. Elk van de drie grote RPM distributies, openSUSE, Fedora en Mandriva, heeft zijn eigen systeem ontwikkeld. Daarnaast is er bovendien Apt4rpm en zijn opvolger Apt-rpm, het naar RPM geporteerde APT van Debian, dat geschikt is voor zowel openSUSE, Fedora als Mandriva. 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 openSUSE, 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.
T/m SUSE Linux 10.1 staat naast Yast de Yast Shell voor Package Management voor het console, geheten y2pmsh, ter beschikking. Deze moet apart worden geïnstalleerd. Het Engelstalige artikel „y2pmsh” op de openSUSE website 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.
Vanaf openSUSE 10.2 is y2pmsh vervangen door het programma zypper. Ook hiermee kan onder meer software worden geïnstalleerd, ge-update en verwijderd, kunnen de installatiebronnen worden beheerd en kan in de software database worden gezocht. Alle mogelijkheden vindt u in zypper’s man-page. Ook de opdracht zypper —help geeft de gewenste informatie, zij het wat minder uitvoerig. Op de openSUSE website vindt u juist meer informatie met bovendien voorbeelden. Als u eenmaal een stel installatiebronnen hebt samengesteld staan u de volgende opdrachten voor het dagelijkse beheer van uw software ter beschikking:
- zypper refresh : voor het ophalen en/of bijwerken van de lijst met beschikbare pakketen.
- zypper update : voor het bijwerken van alle geïnstalleerde pakketten.
- zypper install athena-devel : voor het installeren van een pakket met bij wijze van voorbeeld de basisnaam athena-devel. Hierbij zorgt zypper er voor dat alle pakketten waar athena-devel van afhankelijk is indien nodig ook worden geïnstalleerd.
- zypper remove athena-devel : voor het verwijderen van een pakket met bij wijze van voorbeeld de basisnaam athena-devel.
Zypper geeft u de mogelijkheid binnen een shell te werken, ongeveer zoals zijn voorganger y2pmsh. Deze functionaliteit is echter nieuw en nog niet helemaal vrij van bugs.
T/m openSUSE 10.2 werd ook standaard het Novell Zen software management systeem geïnstalleerd. Voor niet bedrijfsmatig gebruik verdient het aanbeveling dit te verwijderen. Het gaat om de pakketten zmd, zen-updater, rug en libzypp-zmd-backend. Vooral de eerste versies hiervan, vanaf SUSE Linux 10.1, werkten traag en slecht. Sindsdien is Zen sterk verbeterd (er is zelfs een verbeterde versie van SUSE Linux 10.1 uitgekomen), maar werkt het nog steeds vrij traag.
-
> 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.
>> Het instellen van Mandriva repositories gaat tegenwoordig ook heel gemakkelijk via MCC (Mandriva Linux Configuratiecentrum). Op het tabblad „Softwarebeheer” kan men kiezen voor „Mediabronnen voor installatie en herzieningen configureren”. In Mandriva 2008 is dit systeem (drakrpm) sterk verbeterd, men kan nu in één keer alle officiele distributiebronnen laten toevoegen. Via „Optie” / „Aangepaste media toevoegen” kunnen andere bronnen worden toegevoegd, zoals de belangrijke PLF-repositories (Penguin Liberation Front).
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 Wiki en op pagina SysAdmin/Urpmi van de Mandriva Community Wiki. Urpmi heeft een grafische interface met de naam MandrivaUpdate aka RpmDrake. Mandriva’s Wiki vertelt u ook daarover meer.
-
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. openSUSE 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:
Er zijn verschillende grafische interfaces voor Yum. Sinds Fedora Core 5 is Pirut (Package Install and Remove UTility) Fedora’s eigen grafische schil voor het installeren en verwijderen van software, terwijl Pup (Package UPdater) het bijwerken van de software verzorgt. Daarnaast zijn er enkele minder of niet distributiegebonden interfaces beschikbaar:
- Yum Extender is gebaseerd op de GTK interface en speciaal bedoeld voor Fedora. 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 openSUSE is KYum de standaard GUI, maar ook Yumex en de GNOME interface for YUM zijn beschikbaar, t/m versie 10.1 via repositories van derden, en vanaf openSUSE 10.2 in de distributie zelf.
-
Apt4rpm werkt op dezelfde manier als APT. Het is het standaard pakketbeheersysteem van PCLinuxOS, een sinds begin 2007 heel populaire distributie, die is afgeleid van Mandriva. De bijbehorende grafische gebruikersinterface is Synaptic.
