Home - Linux beginners - Software installeren

.

• Webdesign
  
  
• Linux beginners
• Wat is Linux?
• Distributies
• Installatie
• De Console
• Documentatie
• Linux Commando's 1
• Bestandsrechten
• VI-editor
• Bestanden zoeken
• Devices - mounten
• Directory-structuur
• Schijfruimte
• Procesbeheer
• tekstgereedschappen
• Redirection en pipes
• Reguliere expressies
• Het opstart-proces
• Software installeren
• Software zelf compileren
• De kernel
• Links
• Literatuur
• Te doen


• Linux gevorderden
• Contact
  
  
• ©2005, Jan Gnodde

Printbaar

18. Software installeren voor beginners

Een standaard installatie van één van de moderne Linux-distributies zorgt er meestal voor, dat de Linux-gebruiker een rijke keus heeft aan software op zijn of haar computer. Toch zal, soms al snel, soms na verloop van tijd, de behoefte ontstaan aan dat ene programma, dat nu net niet op je harde schijf gezet is. Dan moet dat dus alsnog geïnstalleerd worden. En dan zul je ontdekken, dat bij het installeren van software op een Linuxdoos toch wel wat meer komt kijken dan het draaien van een setup-programma.

Het kost wel enige moeite om toe te geven, maar het installeren van nieuwe programma's is bij Windows beter geregeld dan bij Linux. Bij Windows is meestal het dubbelklikken op een setup.exe en het vervolgens beantwoorden van enkele simpele vragen voldoende om een programma geïnstalleerd te krijgen.
Bij Linux moet je, zelfs voor de software gedownload wordt (of op de CD wordt opgezocht), eerst al antwoord geven op de vraag op welke manier je het programma wilt installeren. En de mogelijke antwoorden op die vraag zijn dan ook nog eens afhankelijk van welke distributie je gebruikt.

Broncode of verpakte binaries

De meeste Linux-programma's worden in de taal C en/of C++ geschreven. Dat schrijven gebeurt in een voor (sommige) mensen nog enigszins leesbare taal: de zgn. broncode (sourcecode). Die broncode wordt door een speciaal programma (de compiler) vertaald in machine-taal (de bekende enen en nullen, waar een normaal mens helemaal geen touw aan vast kan knopen), waarna we een uitvoerbaar programma hebben (een binary). Dat "vertalen" noemen we "compileren".
Het bijzondere van Linux en alle andere opensource software is, dat de broncode van de programma's vrij verkrijgbaar is. Vroeger (en dat is niet eens zo heel lang geleden) was Linux software alléén maar als broncode verkrijgbaar en moest je die zelf, op je eigen computer, compileren. Dat was in de tijd, dat Linux alleen voor nerds en geeks was.
Maar tijden veranderen, en bijna iedere moderne distributie heeft nu een mooie grafische pakket-manager, waarmee software op eenvoudige wijze geïnstalleerd kan worden. Zo'n pakket bevat in de meeste gevallen niet de broncode, maar een reeds gecompileerde versie van het programma, met daarnaast scripts en data, die aangeven, hoe en waar het programma geïnstalleerd en geconfigureerd moet worden.
In een ander artikel zullen we verder ingaan op het zelf compileren van software, maar nu richten we ons op het werken met de verpakte binaries, de zgn. pakketten.

RPM, DEB of PISI

De eerste (bruikbare) pakketmanager kwam van RedHat. Daar heeft men rpm ontwikkeld: de RedHat Packet Manager. Een pakket bestaat nl. niet alleen uit het gecompileerde programma, maar kan ook allerlei bijbehorende bestanden bevatten, zoals configuratie-files. Bovendien bevat het pakket gegevens over waar de verschillende bestanden in de directory-structuur geplaatst moeten worden, enz., enz..
De rpm-pakketmanager is nu algemeen geaccepteerd, en wordt ook door veel andere distributies (o.a. Mandrake, SuSE, Fedora, enz.) gebruikt.

De deb-pakketten zijn van Debian. De Debian-pakketmanager (apt genaamd) heeft de nodige voordelen t.o.v. rpm, en wordt daardoor steeds meer gebruikt.

De pisi-pakketten zijn van Pardus. Pardus is momenteel de enige distributie, die dit systeem gebruikt (het is dan ook door Pardus ontwikkeld). En het is een nieuwer systeem dan rpm en deb. Mede daardoor mist het ook enkele van de nadelen van die twee. Toch kiezen wij bij deze uitleg even voor rpm, omdat dat ook meteen duidelijk maakt, wat de voordelen van apt en pisi zijn.

Grafisch of console

Zoals gezegd kennen bijna alle moderne distributies een mooie grafische pakketmanager. Een nadeel hiervan is echter, dat iedere distributie zijn eigen uitvoering heeft, en ze dus niet universeel toepasbaar zijn. Daarnaast zijn er toch nog Linux-gebruikers die niet grafisch willen of kunnen werken (bv. vanwege hardware-beperkingen). En, tenslotte, maken die grafische pakketmanagers toch maar gewoon (op de achtergrond) gebruik van rpm (of apt, of pisi). Dus kiezen we (voor deze uitleg) voor de pure rpm vanuit de (X-) console.

Afhankelijkheden en bibliotheken

Voor we echt met rpm gaan werken, nog een laatste stukje theorie, dat in de praktijk echter vaak voor problemen kan zorgen: de afhankelijkheden of dependencies.

Er bestaat bijna geen programma, dat onafhankelijk van andere bestanden kan draaien. Bijna alle (Linux-) programma's maken gebruik van zgn. libraries (bibliotheken). Hierin staan tal van functies, waar het programma gebruik van maakt (vergelijkbaar met de dll-bestanden van Windows). Zo kan de windowmanager KDE niet draaien zonder de qt-libraries, en bijna geen enkel Linux-programma kan zonder de standaard C-bibliotheek libc.

Deze bibliotheken zijn dus onmisbaar voor de werking van de programma's die er gebruik van maken. Nu zou het kunnen gebeuren, dat we, bij het installeren van een programma, een foutmelding krijgen, die betrekking heeft op het ontbreken van één of zelfs meer libraries. Dat betekent dan, dat eerst die libraries geïnstalleerd zullen moeten worden. RPM zorgt er helaas niet voor, dat de bibliotheken, waar het programma afhankelijk van is, automatisch mee geïnstalleerd worden. Wel kijkt de pakketmanager of aan alle afhankelijkheden voldaan is voordat tot feitelijke installatie wordt overgegaan. Het missen van een library betekent dus: zoeken op internet of CD's, de library installeren en daarna nogmaals proberen het betreffende pakket te installeren.

Er valt nog veel meer te schrijven over libraries, maar dat valt buiten het kader van dit artikel.

En niet alleen libraries kunnen voor problemen zorgen: soms (vaak) zijn programma's afhankelijk van andere programma's. Bijvoorbeeld: de meeste cd-brandersoftware is afhankelijk van het programma cdrecord. Als geprobeerd wordt een rpm-bestand van zo'n branderprogramma te installeren, zonder dat cdrecord al op de harde schijf staat, maakt rpm duidelijk, dat dat niet gaat.

En nu: installeren

Eh, nee, nog niet. Het is misschien handiger om eerst uit te zoeken of een rpm-pakket wel geïnstalleerd kan worden (denk erom, dat je het programma rpm als root moet draaien, anders krijg je zeker een foutmelding):

rpm -i --test pakketnaam

Deze opdracht geef je vanuit de directory, waar het pakket staat (of je moet het pad naar het pakket erbij aangeven). Het pakket wordt niet echt geïnstalleerd (dankzij optie --test), maar je krijgt wel eventuele foutmeldingen te zien, zoals niet vervulde afhankelijkheden.

Als dit geen problemen geeft, kun je echt gaan installeren.

Het programma rpm kent vele opties, waarvan de belangrijkste zijn:

• -i = installeren
• -U = upgrade
• -e = erase (verwijder).

De optie -e gebruik je om een pakket van je systeem te verwijderen (te deïnstalleren). Gebruik bij deze optie de naam van het pakket zonder de extentie .rpm, anders krijg je waarschijnlijk de melding, dat het pakket niet geïnstalleerd is.

RPM kent nog veel meer opties, o.a. om zelf rpm-pakketten te kunnen maken. Een handige optie om te kijken of een pakket al geïnstallerd is, is de optie -qa, waarmee een lijst van alle ge�stalleerde pakketten getoond wordt. Zo'n lijst is vaak erg lang en dus lastig te doorzoeken, maar je kunt eenvoudig naar het gewenste pakket zoeken door een zgn. pipe:

rpm -qa | grep pakketnaam

Voor nog veel meer opties moet je de manpages van rpm maar eens lezen (man rpm).

De praktijk, de problemen

Al met al lijkt rpm een bijna ideaal stukje gereedschap om software op Linux-systemen te installeren. Het zijn echter de afhankelijkheden en de verschillen tussen de diverse distributies die vaak roet in het eten gooien.
Over de afhankelijkheden hebben we het al gehad. De verschillen tussen de distributies zorgen echter ook vaak voor problemen, en wel doordat distributie X bepaalde bestanden op een andere plaats in de bestandsstructuur neer zet dan distributie Y. Daardoor kan het gebeuren dat het installeren van de CD-brandersoftware niet lukt, ondanks dat het programma cdrecord op de harde schijf staat. Het staat dan domweg niet op de plaats waar het rpm-bestand het verwacht.

Nog erger: een bepaald rpm-bestand kan niet geïnstalleerd worden, omdat bv. glibc.so.6 niet gevonden wordt (zegt rpm), terwijl deze bibliotheek er wel is en ook nog op de juiste plaats staat. Dit kan veroorzaakt worden doordat een andere versie van die bibliotheek gezocht wordt.

En dit soort problemen komen in de praktijk helaas vaak voor. Hoe dat is te voorkomen?
Zorg, dat je een rpm bestand vindt, dat specifiek voor jouw distributie bedoeld is, en als het even kan zelfs voor hetzelfde versienummer van je distributie. Het kan nl. zelfs gebeuren, dat een rpm-bestand voor RedHat 7.2 zich niet laat installeren op RedHat 8.0!

Het best kun je het programma gewoon zoeken op de installatie CD's van je distributie: daar staan vaak veel meer programma's op dan op je computer zijn geïnstalleerd. Mocht je het daar niet kunnen vinden, kijk dan pas op internet en zoek eerst bij de site (of een mirror) van je distributieboer. Als het daar ook niet lukt, dan zul je moeten zoeken in algemenere rpm-bronnen.

Een aanrader is http://www.rpmfind.net/linux/RPM/.

Tenslotte

Het installeren van rpm-bestanden geeft in de praktijk toch vaak problemen (getuige de vele vragen, die hierover bij ons binnen komen). Dit artikel lost die problemen niet allemaal op, maar probeert wel aan te geven, hoe ze zoveel mogelijk voorkomen kunnen worden.

Eén optie van rpm hebben we nog niet besproken: als je zeker weet, dat aan alle afhankelijkheden voldaan is, en rpm blijft toch weigeren het gewenste pakket te installeren, dan kun je eventueel de optie --force gebruiken. Daarmee dwing je rpm het pakket te installeren, ondanks dat (volgens rpm) niet aan alle afhankelijkheden voldaan is.

Maar misschien is het nog beter je eens te verdiepen in het zelf compileren van de software. Dat geeft niet minder problemen, maar heeft wel een aantal voordelen: je kunt de software optimaliseren voor jouw hardware en je beschikt in veel gevallen over meer recente software, omdat het meestal even duurt voordat een rpm-pakket verkrijgbaar is.
Het zelf compileren behandelen we in een ander artikel.

Laatst herzien op 18-12-2006