Platform Linux

De tarball, een meestal met gzip of bzip2 gecomprimeerd tar archief, is het oerpakketformaat van Linux (en de diverse vormen van UNIX). Tarballs hebben geen gestandaardiseerde structuur, zij het dat er bij tarballs met broncode in het algemeen wel van een zekere uniformiteit sprake is. Er is geen specifieke tool om tarballs te installeren, laat staan te upgraden en te deïnstalleren. Lastig is dat aan de naam van een tarball meestal niet is te zien of het om een source of om een binair pakket gaat. Als u het niet weet is het wel zo handig om de inhoud van te voren even te bekijken in een grafische schil of een filemanager. Als u een file ziet met de naam Makefile of Makefile.in gaat het altijd om broncode. Als die file er niet is gaat het meestal om een binair pakket.

De eerste stap bij het installeren van een tarball is altijd het uitpakken in een geschikte directory. Stel dat we een tarball met de naam athena-devel-2.4.3 hebben. Zet deze eerst in de gewenste directory. Als hij niet gecomprimeerd is wordt hij uitgepakt met het commando:

tar -xvf athena-devel-2.4.3.tar

De functie -x staat voor uitpakken (extract) en de optie f (voor „file”) is nodig om daarachter de naam van het pakket te kunnen geven. De optie v (voor „verbose”) laat de computer veel informatie geven over wat hij doet. In het geval van tar ziet u op het scherm een lijst van alle uitgepakte directories en files verschijnen. Is het tar-archief gecomprimeerd met gzip - de extensie is dan .tar.gz of .tgz, dan wordt het als volgt uitgepakt:

tar -xzvf athena-devel-2.4.3.tar.gz

Hier wil de optie z (voor „zip”) zeggen dat het pakket eerst met gzip moet worden gedecomprimeerd en daarna pas kan worden uitgepakt. Een tar-arcief kan ook met bzip2 zijn gecomprimeerd. Dan is zijn extensie .tar.bz2, en wordt hij uitgepakt door de opdracht

tar -xjvf athena-devel-2.4.3.tar.bz2

te geven. Zoals u zult begrijpen staat de optie j voor decomprimeren met bzip2 en dan pas uitpakken.

Omdat tarballs in het merendeel van de gevallen broncode bevatten zullen we eerst de installatie van die pakketten bespreken. Daarna komen de binaire tarballs aan de orde.

 

Tarballs met broncode

Source tarballs bevatten in het algemeen één directory met dezelfde naam als het pakket. Die naam bestaat meestal uit twee delen:

<eigenlijke naam>-<versienummer>

Binnen die directory, die ik verder de root directory van het pakket zal noemen, bevindt zich de eigenlijke inhoud van het pakket.Verspreiders van broncode maken vrijwel altijd gebruik van de mogelijkheden van de GNU programmatuur ( autoconf en automake) voor het automatisch configureren van de broncode voor het systeem en voorbereiden van de compilatie en installatie. In de root directory vinden we dan bestanden met de namen INSTALL en README. In INSTALL staan de belangrijkste instructies voor installatie van het pakket, terwijl in README allerlei nuttige extra informatie over installatie en werking van het programma is te vinden. Verder vinden we het programma configure met behulp waarvan de broncode wordt geconfigureerd en een Makefile wordt aangemaakt Het programma make, dat al op uw systeem behoort te staan, zorgt er vervolgens aan de hand van de Makefile voor dat de broncode wordt gecompileerd en het gecompileerde programma wordt geïnstalleerd.

Het is niet gezegd dat source tarballs altijd deze structuur hebben. Als ze geen gebruik maken van GNU’s autoconf en automake zullen ze al een kant en klare Makefile hebben. Deze hoeft echter niet in de root directory te staan. Vaak zijn er meerdere subdirectories met broncode met elk een eigen Makefile. Er kan dan een centrale Makefile in de root directory staan die ze allemaal aanstuurt. Heel eenvoudige broncode pakketten hebben soms niet eens een Makefile, maar bevatten alleen instructies voor het handmatig compileren, of zelfs dat niet. Het is niet in algemene zin aan te geven hoe dit soort pakketten moet worden behandeld. Lees in elk geval altijd tekstbestanden waar informatie in kan staan, zoals INSTALL en README.

In het vervolg gaan we er van uit dat source tarballs de door de GNU auto-programmatuur opgelegde structuur hebben.

Het is handig om alle broncode die u op uw systeem installeert in één directory te verzamelen. Uitgaande van het feit dat u beheerdersrechten (root permissions) heeft is de aangewezen directory /usr/local/src. Hebt u geen beheersdersrechten dan is een directory src in uw home directory, bijvoorbeeld /home/mathilde/src, wel geschikt. In dat geval moet u ook onder uw home directory installeren.

Het installatieproces verloopt nu in een aantal stappen:

1. Pak het pakket met het geschikte commando (zie hier) uit in de gewenste directory, zeg /usr/local/src. Dank zij de v („verbose”) optie van tar ziet u op het scherm hoe de root directory van het pakket heet. In ons voorbeeld is het athena-devel-2.4.3.

   Het wil een enkele maal wel eens gebeuren dat niet de root directory van het pakket maar de inhoud ervan in de tarball is opgenomen. Niet handig, want alle files en directories van het pakket worden dan in onze uitpakdirectory neergezet, waardoor het een rommeltje wordt. Om dat te voorkomen moet de root directory eerst worden aangemaakt, waarna de tarball met een speciale optie moet worden uitgepakt. Bijvoorbeeld:

   mkdir maya-0.7.3
   tar -xzvf maya-0.7.3.tar.gz -C maya-0.7.3>

   De -C optie gevolgd door een directory heeft tot gevolg dat het pakket in die directory wordt uitgepakt. Dit is nu zo’n geval waarin het handig is de inhoud van de tarball van te voren even te bekijken. Dat kan met de volgende opdracht:

   tar -tzf maya-0.7.3.tar.gz

2. Ga met het cd („change directory”) commando naar de root directory:

   cd athena-devel-2.4.3

3. Voer het script configure uit om de broncode te configureren en een Makefile aan te maken:

   ./configure

   De ./ is nodig omdat de actieve directory (aangeduid met een punt) bij Linux en UNIX niet in de omgevingsvariabele PATH van de systeembeheerder (root) is opgenomen. Als u de opdracht configure geeft zult u zien dat het systeem de opdracht niet kan vinden, ook al ziet u configure wel in de directory staan. Met ./configure lukt het wel.

   configure heeft in veel gevallen parameters. Welke er zijn en welke waarden ze kunnen aannemen kunt u opvragen met ./configure —help. In de meeste gevallen hoeft u geen enkele van die parameters te gebruiken. Als u parameters niet gebruikt krijgen ze een verstekwaarde, die in het merendeel van de gevallen wel voldoet. Toch kan het voorkomen dat voor bepaalde parameters geen algemeen geldige verstekwaarde kon worden gegeven. In dat geval is het van belang om die parameter wel te gebruiken. Aanwijzingen daartoe zult u dan wel in INSTALL vinden. Een parameter die nog als eens wordt gebruikt is de —prefix parameter die aangeeft vanaf welke directory de software moet worden geínstalleerd. Zijn verstekwaarde is vaak /usr/local, maar het kan nuttig zijn om het programma ergens anders te installeren. Zo worden KDE programma’s bij de SUSE distributie normaliter onder /opt/kde geïnstalleerd. De configuratie-opdracht geeft u dan als volgt:

   ./configure —prefix=/opt/kde

   Het kan ook voorkomen dat een programma van verschillende libraries gebruik kan maken om zijn doel te verwezenlijken. Als u één of meer van die libraries niet hebt (op één na natuurlijk) en ze ook niet wilt installeren kunt u door middel van parameters aangeven dat het programma de libraries in kwestie niet moet gebruiken. configure zal er dan ook niet naar zoeken.

   In de output van configure kunt u zien wat het allemaal controleert en naar welke software het zoekt. Als benodigde software niet gevonden wordt geeft configure een foutmelding en stopt het programma. Een voorbeeld is

   „checking for GLIB - version >=2.0.0…no”

   In zo’n geval moet de GLIB library met een versienummer 2.0.0 of hoger met inbegrip van de bijbehorende C header files worden geïnstalleerd voor u verder kunt gaan. De C header files zijn nodig voor het compileren van software die van de library afhankelijk is. Het is heel goed mogelijk dat de library er wel is, maar de header files nog niet. In dat geval zult u een development package van die library nog moeten installeren.

4. Na de configuratie is het tijd voor de compilatie. Deze wordt uitgevoerd met behulp van het programma make aan de hand van de door configure samengestelde Makefile. De Makefile schrijft voor hoe bepaalde doelen, die als parameter worden opgegeven, moeten worden verwezenlijkt. Als make zonder parameters wordt aangeroepen wordt een standaardopdracht uitgevoerd, en dat is normaliter „all”. „All” staat voor compilatie van de volledige software in kwestie. De opdracht tot compilatie luidt dus:

   make

   of

   make all

   Het resultaat van de compilatie zijn zgn. object files met extensie .o. Deze worden tenslotte met een speciaal programma, de „linker”, samengesmeed tot één of meer uitvoerbare programma’s en/of libraries, de zgn. „binaries”.

5. Als in de vorige stap alles is goedgegaan en make niet met een foutmelding is gestopt kan de gecompileerde software worden geïnstalleerd. Ook dit gaat met make, en wel als volgt:

   make install

   En dit is het besluit van de installatieprocedure.

Vooral stap 4 kan door make voortijdig worden beëindigd als gevolg van fouten die door niet-programmeurs niet zo maar zijn op te lossen. Soms is de maker van het programma per e-mail beschikbaar voor ondersteuning, maar in de meeste gevallen is de beste weg om tot een oplossing te komen het stellen van vragen in een geschikte nieuwsgroep op het internet. Als het probleem op zeker ogenblik is opgelost en u de sotware weer wilt gaan compileren moet u eerst de resultaten en tussenresultaten van de vorige configuratie en compilatie verwijderen door de opdracht

make clean

te geven.

Soms biedt de Makefile ook de mogelijkheid tot deïnstallatie van de software. Dat gaat dan met de opdracht:

make deinstall

Helaas bent u meestal op uzelf of op extra tools, zoals checkinstall, aangewezen om uit source tarballs geïnstalleerde software weer te deïnstalleren.

 

Binaire tarballs

Binaire tarballs hebben in tegenstelling tot source tarballs veel minder een uniforme structuur. Hoe de software moet worden geïnstalleerd kan van geval tot geval verschillen. Vaak zal de tarball een tekstfile met de naam INSTALL, README, of iets van dien aard bevatten, waarin aanwijzingen voor installatie worden gegeven. Soms zal de tarball een installatiescript bevatten. Het pakket moet dan worden geïnstalleerd door dat script uit te voeren. Kijk ook dan eerst naar aanwijzingen voor installatie omdat het installatiescript parameters kan hebben die bepalen hoe en waar de software wordt geïnstalleerd.

Het is mogelijk dat de software van het pakket, net als in Slackware pakketten, al helemaal in de juiste directorystructuur is ondergebracht. Het pakket moet dan vanuit een root directory worden geïnstalleerd. Voor absolute directories is dit de root directory van het systeem, /, en voor relatieve directories (zonder / er voor) is het een root directory naar keuze, b.v. /usr/local, /opt of /usr. Dit alles is natuurlijk weer afhankelijk van in het pakket opgenomen aanwijzingen voor installatie.

En voor het overige is het parool: handel naar bevind van zaken.

 

Tools voor tarballs

De grafische desktops KDE en GNOME hebben hun eigen grafische schillen voor het beheer van tarballs. KDE heeft ark voor het bekijken en uitpakken van al dan niet gecomprimeerde tarballs. In plaats van ark kunt u ook karchiver gebruiken. Na het uitpakken van een source tarball kan kconfigure van nut zijn. Het biedt een grafische interface voor het configureren en compileren van broncode en het vervolgens installeren van de software. Voor de GNOME desktop is fileroller een mooie grafische schil voor het beheren van tarballs.

Voordeel van tarballs is dat ze in beginsel voor elk Linux systeem geschikt zijn. Nadeel is dat vaak geen deïnstallatiescript wordt verstrekt, en upgraden kan alleen maar door eerst het oude pakket te deïnstalleren en vervolgens het nieuwe te installeren. Voor tarballs met broncode zijn er zijn verschillende utilities die in deze leemtes beogen te voorzien. Vooral checkinstall is erg handig: het compileert broncode pakketten en converteert het resultaat naar één van de drie package management systemen: RPM, Debian of Slackware. Het gecompileerde pakket kan dan op de voor elk van deze systemen gebruikelijke wijze worden geïnstalleerd, ge-upgrade en indien gewenst weer gedeïnstalleerd. Daarnaast is er make_uninstall, dat eveneens broncode pakketten compileert, het resultaat installeert, en daarbij tevens een deïnstallatiescript aanmaakt. Het gecompileerde pakket kan indien gewenst als binaire tarball worden bewaard.

Last but not least is er stow, een programma van de Free Software Foundation voor het beheer van de installatie van tarballs. Om stow te kunnen gebruiken moeten pakketten in hun eigen pakket directory onder een speciale stow directory (normaliter /usr/local/stow) worden geinstalleerd. In geval van een source tarball kan dat worden gerealiseerd door de gewenste directory als prefix argument van de configuratie opdracht op te geven, bijvoorbeeld:

./configure —prefix=/usr/local/stow/athena-devel-2.4.3

Met stow worden vandaar symbolische links naar de standaard locaties van het pakket gelegd. Zo blijft altijd gemakkelijk te zien uit welke files een bepaald pakket bestaat, en kan het pakket toch normaal worden gebruikt. Als een pakket wordt gedeinstalleerd worden de symbolische links verwijderd, maar de pakket directory blijft bestaan zodat herinstallatie op elk gewenst moment weer mogelijk is. Door ook de pakket directory weg te halen wordt een pakket helemaal van het systeem verwijderd zonder een spoor na te laten. Simpel, maar doeltreffend. Zie ook de inleidingen van de Linux Gazette en van IBM developerWorks.