Feinabstimmung

Das Gentoo-Paketsystem Portage [1] ähnelt den Ports der freien Unix-Variante FreeBSD. Als quellenbasierte Distribution lädt Gentoo vor dem Installieren die Quellcode-Pakete aus dem Internet. Das setzt natürlich einen permanenten Zugang zum weltweiten Netz voraus. Die Quellen eines zu installierenden Pakets stammen direkt von den Seiten der Programmentwickler. Dort liegen sie in aller Regel als Tarball vor.

Das System entpackt das Paket in einen temporären Pfad (voreingestellt ist /var/tmp) um es dort zu kompilieren und danach ins System zu installieren. Vereinfacht dargestellt läuft eine automatisierte Variante eines ./configure && make && make install ab.

Um aber eine gemeinsame Installationsbasis vieler verschiedener Pakete zu gewährleisten, sieht die Wirklichkeit natürlich etwas komplexer aus. So nimmt etwa das Configure-Skript verschiedene Parameter für das Übersetzen des jeweiligen Paketes entgegen. Ferner beeinflussen Compiler-spezifische Umgebungsvariablen das Übersetzen eines Pakets und passen es so an einen Prozessor an, etwa an eine 64-Bit-CPU.

Zentrale Konfiguration

Bei Binary-orientierten Distributionen, wie Novell/Suse, Red Hat/Fedora und den meisten anderen, stecken in den RPM-Paketen generisch vorkompilierte Pakete. Meist optimieren die Entwickler dabei auf i586-Architekturen: Das bedeutet, dass das Programm auf jedem Rechner ab einer Pentium-CPU oder einem AMD K6-2 läuft. Der Grund dafür liegt auf der Hand: Die Programme sollen möglichst auf jedem PC lauffähig sein. Im Fall von 32- und 64-Bit-Anwendungen treten aber erhebliche Unterschiede auf. Daher bieten die Distributoren für diese verschiedene Pakete an.

Gentoo überlässt hingegen das Anpassen der Pakete dem Anwender. Über die zentrale Konfigurationsdatei /etc/make.conf ist es möglich, das Installationsverhalten des Systems zu kontrollieren und die Software auf die Hardware zu optimieren (siehe Kasten Konfigurationsdatei). In der make.conf setzen Sie die Flags [2] für den C- und den C++-Compiler, die für beide meist identisch sind.

Das Verwenden von Compiler-Flags erlaubt es, ein Paket für eine bestimmte Rechnerarchitektur anzupassen und zu optimieren – seien es die 32- und 64-Bit-Varianten von Intel oder AMD, PowerPCs, Sparcs oder Alphas. Dieser Tatsache hat Gentoo den nicht unbegründeten und schon häufig unter Beweis gestellten Ruf eingetragen, auf jeder Architektur zu laufen.

Aber auch andere für das Übersetzen notwendige Umgebungsvariablen finden Platz in der Datei make.conf. Ein Beispiel ist die Umgebungsvariable LINGUAS="de" für das Paket kde-base/kde-i18n, welches die deutsche Sprache für KDE installiert.

Installieren mit Emerge

Der Befehl emerge leitet unter Gentoo eine Installation ein. Vorher sollte man sich die Man-Page genauer ansehen, da Emerge etliche Optionen bietet und die Ausgabe mitunter einige Fragen aufwirft. Ein einfaches emerge Programmname reicht zum Installieren eines Paketes. Wer mit der Kommandozeile auf dem Kriegsfuß steht, dem ermöglichen alternativ grafische Frontends, wie das KDE-Programm Kuroo (Abbildung 1), das installieren und konfigurieren von Software.

Abbildung 1: Ein grafisches Frontend wie Kuroo vereinfacht das Arbeiten mit dem Gentoo-Paketsystem Portage.

Vorher gilt es aber sicherheitshalber noch zu prüfen, welche Abhängigkeiten das Paket hat und vor allem welche USE-Flags noch gesetzt sein sollten (siehe Kasten "Konfigurationsdatei"). Das erledigt der Befehl emerge -pv Programmname . Dabei steht p für "pretend": Emerge simuliert die Installation lediglich und löst dabei die Abhängigkeiten auf. Für ausführliche Verlaufsmeldungen sorgt v wie "verbose".

Listing 1 zeigt die entsprechende Ausgabe bei der Einrichtung von Xfig auf einem Rechner mit bereits installiertem X.org. Das N hinter ebuild bedeutet hier, dass das Paket neu und noch nicht installiert ist. Stünde eine Position weiter ein R, wäre das Paket bereits eingerichtet.

# emerge -pv xfig
These are the packages that I would merge, in order:
Calculating dependencies …done!
[ebuild  N    ] media-libs/urt-3.1b-r1  +X +gif -gs +tiff 992 kB
[ebuild  N    ] media-libs/jbigkit-1.6-r1  396 kB
[ebuild  N    ] media-libs/jasper-1.701.0  +jpeg +opengl 1,329 kB
[ebuild  N    ] media-libs/netpbm-10.30-r1  +jpeg +png +svga +tiff +zlib 2,542 kB
[ebuild  N    ] x11-libs/Xaw3d-1.5-r1  277 kB
[ebuild  N    ] media-gfx/transfig-3.2.4-r1  318 kB
[ebuild  N    ] media-gfx/xfig-3.2.4-r1  5,043 kB
Total size of downloads: 10,901 kB

Bei vielen Abhängigkeiten des Paketes handelt es sich um Zusatzpakete oder gar Bibliotheken, die nicht zum Arbeitsalltag gehören. Um dahinter zu kommen, was sich beispielsweise hinter urt-3.1b-r1 verbirgt, genügt eine Suche mit emerge -s urt: Sie spuckt unter anderem das Paket media-libs/urt aus und beschreibt es als Bibliothek zum Behandeln von Rastergrafiken (Bitmaps).

Genauere Informationen liefert aber die Online-Suche in der Paketdatenbank im Internet [3]. Neben einem kurzem Text, der das Paket beschreibt, gibt die Seite auch Auskunft über die verwendbaren USE-Flags. Im Beispiel in Listing 1 nicht gesetzt ist das USE-Flag gs, angezeigt durch ein Minus davor. Bei gesetztem Flag übersetzt Emerge das Paket mit Ghostscript-Unterstützung.

Für den Einsatz des USE-Flags gibt es zwei Möglichkeiten: Auf der Kommandozeile übergeben Sie die Variable mit USE="gs"; emerge -pv xfig direkt an Emerge. Sicherer ist es, das Flag in der make.conf einzutragen. Das stellt sicher, dass auch ein späteres System-Update das Paket wieder mit Ghostscript-Unterstützung installiert.

Bei entsprechend gesetztem USE-Flag erscheint das Paket media-libs/urt mit +gs in der Pretend-Anfrage. Ist das Paket app-text/ghostscript noch nicht installiert, zeigt Emerge dieses als weitere Abhängigkeit an.