Gentoo Linux ppc64 Handbuch: Arbeiten mit Gentoo

Willkommen bei Portage

Portage ist eine der bemerkenswertesten Innovationen von Gentoo im Bereich der Softwareverwaltung. Mit seiner hohen Flexibilität und der enormen Anzahl an Funktionen wird es häufig als das beste Software-Management-Tool für Linux angesehen.

Portage ist vollständig in Python und Bash geschrieben und daher für die Benutzer vollständig sichtbar, da beides Skriptsprachen sind.

Die meisten Benutzer werden mit Portage über das emerge Werkzeug arbeiten. Dieses Kapitel ist nicht dazu gedacht, die Informationen aus der emerge Handbuchseite zu duplizieren. Für eine vollständige Auflistung der Optionen von emerge, konsultieren Sie bitte die Handbuchseite:

user $man emerge

Gentoo-Repositorium

Ebuilds

Wenn in der Dokumentation von Gentoo von Paketen die Rede ist, sind damit Softwaretitel gemeint, die den Gentoo-Benutzern über das Gentoo-Repositorium zur Verfügung stehen. Dieses Repositorium ist eine Sammlung von Ebuilds, Dateien, die alle Informationen enthalten, die Portage benötigt, um Software zu warten (installieren, suchen, abfragen, etc.). Diese Ebuilds befinden sich standardmäßig in /var/db/repos/gentoo.

Wann immer jemand Portage auffordert, eine Aktion in Bezug auf Softwaretitel durchzuführen, wird es die Ebuilds auf dem System als Grundlage verwenden. Es ist daher wichtig, die Ebuilds auf dem System regelmäßig zu aktualisieren, damit Portage über neue Software, Sicherheitsupdates usw. informiert ist.

Aktualisieren des Gentoo-Repositoriums

Das Gentoo-Repositorium wird normalerweise mit rsync aktualisiert, einem schnellen inkrementellen Dateitransferprogramm. Das Aktualisieren ist ziemlich einfach, da der Befehl emerge ein Front-End für rsync bereitstellt:

root #emerge --sync

Manchmal gibt es Firewall-Einschränkungen, die verhindern, dass rsync die Spiegelserver kontaktiert. In diesem Fall kann das das Gentoo-Repositorium mit Hilfe der täglich erzeugten Snapshots von Gentoo aktualisiert werden. Das Tool emerge-webrsync holt sich automatisch den neusten Snapshot und installiert ihn auf dem System:

root #emerge-webrsync

Wartung von Software

Suche nach Software

Es gibt mehrere Möglichkeiten, das Gentoo-Repositorium, nach Software zu durchsuchen. Eine Möglichkeit is durch emerge selbst. Standardmäßig gibt emerge --search die Namen der Pakete zurück, deren Titel (entweder vollständig oder teilweise) mit dem Suchbegriff übereinstimmen.

Zum Beispiel, um nach allen Paketen zu suchen, die "pdf" in ihrem Namen haben:

user $emerge --search pdf

Um auch die Beschreibung zu durchsuchen, verwenden Sie die Option --searchdesc (oder -S):

user $emerge --searchdesc pdf

Beachten Sie, dass die Ausgabe eine Vielzahl von Informationen liefert. Die Felder sind eindeutig beschriftet, so dass wir nicht weiter auf ihre Bedeutung eingehen werden:

CODE Beispielhafte Ausgabe für einen Suchbefehl

*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Installation der Software

Wenn ein Softwaretitel gefunden wurde, ist die Installation nur noch einen emerge Befehl entfernt. Zum Beispiel, um gnumeric zu installieren:

root #emerge --ask app-office/gnumeric

Da viele Anwendungen voneinander abhängen, kann jeder Versuch, ein bestimmtes Softwarepaket zu installieren, auch die Installation mehrerer Abhängigkeiten nach sich ziehen. Machen Sie sich keine Sorgen, Portage kann gut mit Abhängigkeiten umgehen. Um herauszufinden, was Portage installieren würde, fügen Sie die Option --pretend hinzu. Zum Beispiel:

root #emerge --pretend gnumeric

Um dasselbe zu tun, aber interaktiv zu entscheiden, ob die Installation fortgesetzt werden soll oder nicht, fügen Sie das --ask-Flag hinzu:

root #emerge --ask gnumeric

Während der Installation eines Pakets wird Portage den notwendigen Quellcode aus dem Internet herunterladen (falls notwendig) und standardmäßig in /var/cache/distfiles speichern. Danach wird es das Paket entpacken, kompilieren und installieren. Um Portage anzuweisen, nur die Quellen herunterladen, ohne sie zu installieren fügen Sie die Option --fetchonly zum emerge Befehl hinzu:

root #emerge --fetchonly gnumeric

Dokumentation der installierten Pakete finden

Viele Pakete werden mit einer eigenen Dokumentation ausgeliefert. Manchmal bestimmt das doc USE-FLag, ob die Paketdokumentation installiert werden soll oder nicht. Um zu sehen, ob das doc USE-Flag von einem Paket verwendet wird, verwenden Sie emerge -vp kategorie/paket:

root #emerge -vp media-libs/alsa-lib

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild   R    ] media-libs/alsa-lib-1.1.3::gentoo  USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB

Der beste Weg, das doc USE-Flag zu aktivieren, ist es, dies auf einer paketweisen Basis über /etc/portage/package.use zu tun, so dass nur die Dokumentation für die gewünschten Pakete installiert wird. Für weitere Informationen lesen Sie den Abschnitt USE-Flags.

Sobald das Paket installiert ist, befindet sich seine Dokumentation in der Regel in einem Unterverzeichnis mit dem Namen des Pakets im Verzeichnis /usr/share/doc:

user $ls -l /usr/share/doc/alsa-lib-1.1.3

total 16
-rw-r--r-- 1 root root 3098 Mar  9 15:36 asoundrc.txt.bz2
-rw-r--r-- 1 root root  672 Mar  9 15:36 ChangeLog.bz2
-rw-r--r-- 1 root root 1083 Mar  9 15:36 NOTES.bz2
-rw-r--r-- 1 root root  220 Mar  9 15:36 TODO.bz2

Ein sicherer Weg, um installierte Dokumentationsdateien aufzulisten ist die Verwendung der --filter Option von equery. equery wird zur Abfrage der Portage Datenbank verwendet und ist Teil des Pakets app-portage/gentoolkit:

user $equery files --filter=doc alsa-lib

 * Searching for alsa-lib in media-libs ...
 * Contents of media-libs/alsa-lib-1.1.3:
/usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2
/usr/share/doc/alsa-lib-1.1.3/NOTES.bz2
/usr/share/doc/alsa-lib-1.1.3/TODO.bz2
/usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2

Die Option --filter kann mit anderen Regeln verwendet werden, um die Installationsorte für viele andere Dateitypen anzuzeigen. Zusätzliche Funktionen können in der Handbuchseite von equery nachgelesen werden: man 1 equery.

Entfernen von Software

Um Software sicher von einem System zu entfernen, verwenden Sie emerge --deselect. Dies teilt Portage mit, dass ein Paket nicht mehr benötigt wird und für eine Bereinigung durch --depclean geeignet ist.

root #emerge --deselect gnumeric

Wenn ein Paket nicht mehr ausgewählt ist, verbleiben das Paket und seine Abhängigkeiten, die bei der Installation automatisch installiert wurden, auf dem System. Um Portage alle Abhängigkeiten aufspüren zu lassen, die nun entfernt werden können, verwenden Sie die --depclean Funktionalität von emerge, die später dokumentiert wird.

Aktualisieren des Systems

Um das System in perfekter Form zu halten (und ganz zu schweigen von der Installation der neuesten Sicherheitsupdates), ist es notwendig, das System regelmäßig zu aktualisieren. Da Portage nur die Ebuilds im Gentoo-Repositorium prüft, ist das erste was zu tun ist, dieses Repositorium mit emerge --sync zu aktualisieren. Dann kann das System mit emerge --deep --update @world aktualisiert werden.

Portage wird mit --deep nach neueren Versionen der installierten Anwendungen suchen. Ohne --deep überprüft es nur die Versionen der explizit installierten Anwendungen (die in /var/lib/portage/world aufgelisteten Anwendungen) - es überprüft nicht gründlich deren Abhängigkeiten. Diese Option sollte daher fast immer verwendet werden:

root #emerge --update --deep @world

Der Standard-Upgrade-Befehl sollte --changed-use oder --newuse enthalten, da sich möglicherweise die Profile des Repositoriums geändert haben, oder wenn die USE-Einstellungen des Systems verändert wurden. Portage prüft dann, ob die Änderung die Installation neuer Pakete oder die Neukompilierung bestehender Pakete erfordert:

root #emerge --update --deep --newuse @world

Metapakete

Einige Pakete im Gentoo-Repositorium haben keinen wirklichen Inhalt, sondern werden verwendet, um eine Sammlung von Paketen zu installieren. Zum Beispiel installiert das Paket kde-plasma/plasma-meta den KDE Plasma Desktop auf den System, indem es verschiedene Plasma-bezogene Pakete als Abhängigkeiten einbezieht.

Um ein solches Paket aus dem System zu entfernen, hat die Ausführung von emerge --deselect für das Paket keine große Wirkung, da die Abhängigkeiten für das Paket im System verbleiben.

Portage hat auch die Funktionalität verwaiste Abhängigkeiten zu entfernen, aber da die Verfügbarkeit von Software dynamisch abhängig ist, ist es wichtig, zuerst das gesamte System vollständig zu aktualisieren, einschließlich der neuen Änderungen, die beim Ändern von USE-Flags angewendet werden. Danach kann man emerge --depclean ausführen, um die verwaisten Abhängigkeiten zu entfernen. Wenn dies geschehen ist, kann es notwendig sein, die Anwendungen, die dynamisch mit den nun entfernten Softwaretiteln gelinkt waren, diese aber nicht mehr benötigen, neu zu erstellen, obwohl Portage kürzlich Unterstützung dafür hinzugefügt wurde.

All dies wird mit den folgenden zwei Befehlen gehandhabt:

root #emerge --update --deep --newuse @world

root #emerge --ask --depclean

Lizenzen

Beginnend mit Portage Version 2.1.7 ist es möglich, die Installation von Software auf Basis ihrer Lizenz zu akzeptieren oder abzulehnen. Alle Pakete im Baum enthalten einen LICENSE-Eintrag in ihren Ebuilds. Wenn Sie emerge --search kategorie/paket ausführen, wird die Lizenz des Pakets angezeigt.

Wichtig
{{{1}}}

Standardmäßig erlaubt Portage Lizenzen, die explizit von der Free Software Foundation oder der Open Source Initiative genehmigt wurden oder die der Free Software Definition folgen.

Die Variable, die die erlaubten Lizenzen kontrolliert, heißt ACCEPT_LICENSES und kann in der Datei /etc/portage/make.conf gesetzt werden. Im nächsten Beispiel wird dieser Standardwert gezeigt:

DATEI /etc/portage/make.confDie Standardeinstellung von ACCEPT_LICENSE

ACCEPT_LICENSE="-* @FREE"

Mit dieser Konfiguration können Pakete mit einer Lizenz für freie Software oder Dokumentation installiert werden. Unfreie Software ist nicht installierbar.

Es ist möglich ACCEPT_LICENSE global in /etc/portage/make.conf zu setzten, oder es für jedes Paket in der Datei /etc/portage/package.license anzugeben.

Um zum Beispiel die Lizenz google-chrome für das Paket www-client/google-chrome zuzulassen, fügen Sie Folgendes zu /etc/portage/package.license hinzu:

DATEI /etc/portage/package.licenseAkzeptieren der google-chrome-Lizenz für das google-chrome Paket

www-client/google-chrome google-chrome

Dies erlaubt die Installation des Pakets www-client/google-chrome, verbietet aber die Installation des Pakets ww-plugins/chrome-binary-plugins, auch wenn es die gleiche Lizenz hat.

Or to allow the often-needed sys-kernel/linux-firmware:

DATEI /etc/portage/package.licenseAccepting the licenses for the linux-firmware package

# Accepting the license for linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Accepting any license that permits redistribution
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

Wichtig
Lizenzen werden im Verzeichnis /var/db/repos/gentoo/licenses/ gespeichert, und Lizenzgruppen werden in der Datei /var/db/repos/gentoo/profiles/license_groups gespeichert. Der erste Eintrag jeder Zeile in GROSSBUCHSTABEN ist der Name der Lizenzgruppe, und jeder weitere Eintrag ist eine einzelne Lizenz.

Lizenzgruppen, die in der ACCEPT_LICENSE Variable definiert sind, werden mit einem @ Zeichen vorangestellt. Eine mögliche Einstellung (welche die frühere Portage-Einstellung war) ist es, alle Lizenzen zuzulassen, außer End User License Agreements (EULAs), die das Lesen und Unterschreiben einer Akzeptanzvereinbarung erfordern. Um dies zu erreichen, akzeptieren Sie alle Lizenzen (mit *) und entfernen Sie dann die Lizenzen in der EULA-Gruppe wie folgt:

DATEI /etc/portage/make.confAlle Lizenzen außer EULAs akzeptierenlang=bash

ACCEPT_LICENSE="* -@EULA"

Beachten Sie, dass diese Einstellung auch unfreie Software und Dokumentation akzeptiert.

Wenn Portage sich beschwert

Terminologie

Wie bereits erwähnt, ist Portage extrem leistungsfähig und unterstützt viel Funktionen, die anderen Software-Management-Tools fehlen. Um dies zu verstehen, erläutern wir einige Aspekte von Portage, ohne zu sehr ins Detail zu gehen.

Mit Portage können verschiedene Versionen eines einzelnen Pakets auf einem System koexistieren. Während andere Distributionen dazu neigen, ihre Pakete nach diesen Versionen zu benennen (wie gtk+2 und gtk+3), verwendet Portage eine Technologie namens SLOT. Ein Ebuild deklariert einen bestimmten SLOT für seine Version. Ebuilds mit verschiedenen SLOTs können auf dem gleichen System koexistieren. Zum Beispiel hat das gtk+ Paket Ebuilds mit SLOT="2" und SLOT="3".

Es gibt auch Pakete, die dieselbe Funktionalität bieten, aber anders implementiert sind. Zum Beispiel sind metalogd, sysklogd und sylog-ng alle Systemlogger. Anwendungen, die auf die Verfügbarkeit "eines Systemloggers" angewiesen sind, können sich nicht auf z.B. metalogd verlassen, da die anderen Systemlogger eine genauso gute Wahl sind wie jeder andere. Portage erlaubt virtuelle Pakete: jeder Systemlogger wird als "exklusive" Abhängigkeit des Logging-Dienstes im virtuellen Logger-Paket der virtual Kategorie aufgelistet, so dass Anwendungen von dem virtual/logger-Paket abhängen können. Bei der Installation zieht das Paket das erste im Paket erwähnte Logging-Paket heran, es sei denn, es wurde bereits ein Logging-Paket installiert (in diesem Fall ist das virtuelle Paket befriedigt).

Software im Gentoo-Repositorium kann sich in verschiedenen Zweigen befinden. Standardmäßig akzeptiert das System nur Pakete, die Gentoo als stabil einstuft. Die meisten neuen Softwaretitel werden, wenn sie committed werden, dem Testing-Zweig hinzugefügt, was bedeutet, dass weitere Tests durchgeführt werden müssen, bevor sie es als stabil markieren werden. Obwohl sich die Ebuilds für diese Software im Gentoo-Repositorium befinden, wird Portage sie nicht aktualisieren, bevor sie in dem stabilen Zweig aufgenommen werden.

Manche Software ist nur für einige wenige Architekturen verfügbar. Oder die Software funktioniert nicht auf den anderen Architekturen, oder sie muss noch weiter getestet werden, oder der Entwickler, der die Software in das Gentoo-Repositorium aufgenommen hat, ist nicht in der Lage zu überprüfen, ob das Paket auf verschiedenen Architekturen funktioniert.

Jede Gentoo-Installation hält sich auch an ein bestimmtes Profil, das neben anderen Informationen die Liste der Pakete enthält, die für ein normal funktionierendes System erforderlich sind.

Blockierte Pakete

CODE Portage-Warnung über blockierte Pakete

[ebuild  N     ] x11-wm/i3-4.20.1  USE="-doc -test"
[blocks B      ] x11-wm/i3 ("x11-wm/i3" is soft blocking x11-wm/i3-gaps-4.20.1)

 <div lang="en" dir="ltr" class="mw-content-ltr">
* Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.
</div>

  <div lang="en" dir="ltr" class="mw-content-ltr">
(x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
    x11-wm/i3
</div>

  (x11-wm/i3-gaps-4.20.1-1:0/0::gentoo, installed) pulled in by
    x11-wm/i3-gaps required by @selected

Ebuilds enthalten spezifische Felder, die Portage über ihre Abhängigkeiten informieren. Es gibt zwei mögliche Abhängigkeiten: Build-Abhängigkeiten, die in der DEPEND deklariert sind und Laufzeit-Abhängigkeiten, die in der RDEPEND Variable deklariert sind. Wenn eine dieser Abhängigkeiten ein Paket oder Virtual explizit als nicht kompatibel markiert, löst dies eine Blockade aus.

Während die neueren Versionen von Portage intelligent genug sind, um kleinere Blockaden ohne Benutzereingriff zu umgehen, müssen solche Blockaden gelegentlich manuell gelöst werden.

Um eine Blockade zu beheben, können Benutzer wählen, ob sie das Paket nicht installieren oder das konfligierende Paket zuerst deinstallieren wollen. Im angegebenen Beispiel kann man sich dafür entscheiden, x11-wm/i3 zu installieren oder x11-wm/i3-gaps zuerst zu entfernen. Es ist normalerweise am besten, Portage einfach mitzuteilen, dass das Paket nicht mehr erwünscht ist, z.B. mit emerge --deselect x11-wm/i3-gaps, um es aus der world-Datei zu entfernen, anstatt das Paket selbst gewaltsam zu entfernen.

Manchmal gibt es auch blockierende Pakete mit bestimmten Atoms, wie z.B. <media-video/mplayer-1.0_rc1-r2. In diesem Fall könnte eine Aktualisierung auf eine neuere Version des blockierenden Pakets die Blockierung aufheben.

Es ist auch möglich, dass zwei Pakete, die noch nicht installiert sind, sich gegenseitig blockieren. In diesem seltenen Fall versuchen Sie herauszufinden, warum beide installiert werden müssen. In den meisten Fällen reicht es aus, wenn nur eines der Pakete installiert ist. Falls nicht, melden Sie bitte einen Bug auf Gentoo's Bug-tracking System.

Maskierte Pakete

CODE Portage-Warnung über maskierte Pakete

!!! all ebuilds that could satisfy "bootsplash" have been masked.

CODE Portage-Warnung über maskierte Pakete - Grund

!!! possible candidates are:
  
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

Wenn sie versuchen, ein Paket zu installieren, dass nicht für das System verfügbar ist, tritt dieser Maskierungsfehler auf. Benutzer sollten versuchen, eine andere Anwendung zu installieren, die für das System verfügbar ist, oder warten, bis das Paket als verfügbar markiert ist. Es gibt immer einen Grund, warum ein Paket maskiert ist:

Grund für Maskierung	Beschreibung
~arch Schlüsselwort	Die Anwendung ist nicht ausreichend getestet, um in den stabilen Zweig aufgenommen zu werden. Warten Sie ein paar Tage oder Wochen und versuchen Sie es erneut.
-arch Schlüsselwort oder -* Schlüsselwort	Die Anwendung funktioniert nicht auf der Zielarchitektur. Wenn Sie glauben, dass das Paket funktioniert, dann bitte melden Sie einen Bug.
fehlendes Schlüsselwort	Die Anwendung wurde noch nicht auf der Zielarchitektur getestet. Bitten Sie das Architektur-Portierungsteam, das Paket zu testen, oder testen Sie es für sie und melden Sie die Ergebnisse auf Gentoo's Bugzilla Webseite. Siehe /etc/portage/package.accept_keywords und Akzeptieren eines Keywords für ein einzelnes Paket.
package.mask	Das Paket wurde als beschädigt, instabil oder schlimmer eingestuft und absichtlich als nicht verwendbar markiert.
profile	Das Paket wurde als nicht geeignet für das aktuelle Profil befunden. Die Anwendung könnte das System beschädigen, wenn sie installiert wird, oder sie ist einfach nicht mit dem aktuell verwendeten Profil kompatibel.
license	Die Lizenz des Pakets ist nicht kompatibel mit dem ACCEPT_LICENSE Wert. Erlauben Sie die Lizenz oder die richtige Lizenzgruppe, indem Sie sie in /etc/portage/make.conf oder in /etc/portage/package.license setzen.

Erforderliche USE-Flag-Änderungen

CODE Portage-Warnung über USE-Flag-Wechselpflicht

The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

Die Fehlermeldung kann auch wie folgt angezeigt werden, wenn --autounmask nicht gesetzt ist:

CODE Portage-Fehler über USE-Flag-Wechselanforderung

emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Eine solche Warnung oder ein solcher Fehler tritt auf, wenn ein Paket zur Installation angefordert wird, das nicht nur von einem anderen Paket abhängt, sondern auch erfordert, dass dieses Paket mit einem bestimmten USE-Flag (oder einem Satz von USE-Flags) gebaut wird. Im angegebenen Beispiel muss das Paket app-text/feelings mit USE="test" gebaut werden, aber dieses USE-Flag ist auf dem System nicht gesetzt.

Um dies zu beheben, fügen Sie entweder das gewünschte USE-Flag zu den globalen USE-Flags in /et/portage/make.conf hinzu, oder setzen Sie es für das spezifische Paket in /etc/portage/package.use.

Fehlende Abhängigkeiten

CODE Portage-Warnung über fehlende Abhängigkeiten

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
  
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.

Die zu installierende Anwendung hängt von einem anderen Paket ab, das für das System nicht verfügbar ist. Bitte prüfen Sie in Bugzilla, ob das Problem bekannt ist, und wenn nicht, melden Sie es bitte. Sofern das System nicht so konfiguriert ist, dass es Zweige mischt, sollte dies nicht auftreten und ist daher eine Fehler.

Mehrdeutige Ebuild-Namen

CODE Portage-Warnung über mehrdeutige Ebuild-Namen

[ Results for search key : listen ]
[ Applications found : 2 ]
  
*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD
  
*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2
  
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

Die für die Installation ausgewählte Anwendung hat einen Namen, der mehr als einem Paket entspricht. Geben Sie auch den Kategorienamen an, um dies zu klären. Portage informiert den Benutzer über mögliche Übereinstimmungen, aus denen er wählen kann.

Zirkuläre Abhängigkeiten

CODE Portage-Warnung über zirkuläre Abhängigkeiten

!!! Error: circular dependencies: 
  
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

Zwei (oder mehr) zu installierende Pakete hängen voneinander ab und können daher nicht installiert werden. Dies ist höchstwahrscheinlich ein Fehler in einem der Pakete aus dem Gentoo-Repositorium. Bitte synchronisieren Sie nach einer Weile erneut und versuchen Sie es erneut. Es könnte auch von Vorteil sein, in Bugzilla nachzuschauen, ob das Problem bekannt ist und wenn nicht, es zu melden.

Fetch fehlgeschlagen

CODE Portage-Warnung über fehlgeschlagenen Abruf

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

Portage war nicht in der Lage, die Quellen für die angegebene Anwendung herunterzuladen und wird versuchen, die Installation der anderen Anwendungen (falls zutreffend) fortzusetzen. Dieser Fehler kann auf einen Spiegelserver zurückzuführen sein, der nicht korrekt synchronisiert wurde, oder weil das Ebuild auf einen falschen Ort verweist. Der Server, auf dem sich die Quellen befinden, kann auch aus irgendeinem Grund nicht erreichbar sein.

Versuchen Sie es nach einer Stunden erneut, um zu sehen, ob das Problem weiterhin besteht.

Systemprofilschutz

CODE Portage-Warnung über ein profilgeschütztes Paket

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

Der Benutzer hat darum gebeten, ein Paket zu entfernen, das zu den Kernpaketen des Systems gehört. Es ist im Profil als erforderlich aufgeführt und sollte daher nicht aus dem System entfernt werden.

Digest-Überprüfungsfehler

CODE Fehler bei der Digest-Überprüfung

>>> checking ebuild checksums
!!! Digest verification failed:

Dies ist ein Zeichen dafür, dass etwas mit dem Gentoo-Repositorium nicht stimmt - oft verursacht durch einen Fehler beim Übertragen eines Ebuilds in das Gentoo-Ebuild-Repositorium.

Wenn die Überprüfung des Digests fehlschlägt, versuchen Sie nicht, das Paket selbst erneut zu digesten. Das Ausführen von ebuild foo manifest wird das Problem nicht beheben; es könnte es sogar noch schlimmer machen.

Warten Sie stattdessen ein oder zwei Stunden, bis sich das Repositorium beruhigt hat. Es ist wahrscheinlich, dass der Fehler sofort bemerkt wurde, aber es kann ein wenig dauern, bis die Korrektur angekommen ist. Schauen Sie auf Bugzilla nach, ob schon jemand das Problem gemeldet hat oder fragen Sie auf #gentoo (webchat) (IRC). Wenn nicht, machen Sie weiter und melden Sie einen Bug für das defekte Ebuild.

Sobald der Fehler behoben ist, synchronisieren Sie das Gentoo-Ebuild-Repositorium erneut, um den korrigierten Digest zu übernehmen.

Wichtig
Achten Sie darauf, das Gentoo-Ebuild-Repositorium nicht öfter als einmal am Tag zu synchronisieren. Wie in den offiziellen Gentoo-Netiquette-Richtlinien angegeben (sowie bei der Ausführung von emerge --sync), werden Benutzer, die zu oft synchronisieren, für eine gewisse Zeit von weiteren Synchronisierungen ausgeschlossen. Benutzer, die sich wiederholt nicht an diese Regeln halten, können mit einem harten Bann belegt werden. Wenn es nicht unbedingt notwendig ist, ist es oft am besten, mit der Synchronisation 23 Stunden zu warten, damit die erneute Synchronisation nicht die rsync-Mirror von Gentoo überlastet.

Was sind USE-Flags

Die Idee hinter USE-Flags

Bei der Installation von Gentoo treffen die Benutzer Entscheidungen, die von der Umgebung abhängen, in der Sie arbeiten. Ein Setup für einen Server unterscheidet sich von einem Setup für eine Workstation. Eine Gaming-Workstation unterscheidet sich von einer 3D-Rendering-Workstation.

Dis gilt nicht nur für die Auswahl der zu installierenden Pakete, sondern auch dafür, welche Funktionen ein bestimmtes Paket unterstützen sollte. Wenn es keinen Bedarf für OpenGL gibt, warum sollte sich jemand die Mühe machen, OpenGL zu installieren und zu pflegen und OpenGL-Unterstützung in die meisten Pakete einbauen? Wenn jemand KDE nicht benutzen will, warum sollte er sich die Mühe machen, Pakete mit KDE-Unterstützung zu kompilieren, wenn diese Pakete auch ohne einwandfrei funktionieren.

Um den Benutzer die Entscheidung zu erleichtern, was er installieren/aktivieren soll und was nicht, wollte Gentoo, dass der Benutzer seine Umgebung auf einfache Art und Weise spezifizieren kann. Dies zwingt den Benutzer zu entscheiden, was er wirklich will und erleichtert Portage den Prozess, sinnvolle Entscheidungen zu treffen.

Definition einer USE-Flag

Betreten Sie das Gebiet der USE-Flags. Ein solches Flag ist ein Schlüsselwort, das die Unterstützung und Abhängigkeitsinformationen für ein bestimmtes Konzept beinhaltet. Wenn ein bestimmtes USE-Flag auf aktiviert gesetzt ist, dann weiß Portage, dass der Systemadministrator Unterstützung für das gewählte Schlüsselwort wünscht. Natürlich kann dies die Abhängigkeitsinformationen für ein Paket verändern. Abhängig vom USE-Flag kann es erforderlich sein, dass viele weitere Abhängigkeiten hinzugezogen werden müssen, um die gewünschten Abhängigkeitsänderungen zu erfüllen.

Schauen Sie sich ein konkretes Beispiel an: das kde USE-Flag. Wenn dieses Flag in der USE-Variable nicht gesetzt ist (oder wenn dem Wert ein Minuszeichen vorangestellt ist: -kde), dann werden alle Pakete, die optionale KDE-Unterstützung haben ohne KDE-Unterstützung kompiliert. Alle Pakete, die eine optionale KDE-Abhängigkeit haben, werden ohne Installation der KDE-Bibliotheken (als Abhängigkeit) installiert.

Wenn das kde Flag auf enabled gesetzt ist, dann werden diese Pakete mit KDE Unterstützung kompiliert und die KDE Bibliotheken werden als Abhängigkeit installiert.

Durch die korrekte Definition von USE-Flags wird das System speziell auf die Bedürfnisse des Systemadministrators zugeschnitten.

Verwendung von USE-Flags

Dauerhafte USE-Flags deklarieren

Alle USE-Flags werden innerhalb der Variable USE deklariert. Um es den Benutzern leicht zu machen, USE-Flags zu suchen und auszuwählen, bieten wir bereits eine Standard-USE-Einstellung an. Diese Einstellung ist eine Sammlung von USE-Flags, von denen wir glauben, dass sie von Gentoo-Benutzern häufig verwendet werden. Diese Standardeinstellung wird in den make.defaults Dateien deklariert die Teil des gewählten Profils sind.

Das Profil, auf das das System hört, wird durch den Symlink /etc/portage/make.profile angegeben. Jedes Profil arbeitet auf anderen Profilen aufbauend, und das Endergebnis ist daher die Summe aller Profile. Das oberste Profil ist das Basisprofil /var/db/repos/gentoo/profiles/base.

Um die derzeit aktiven USE-Flags (vollständig) anzuzeigen, verwenden Sie emerge --info:

root #emerge --info | grep ^USE

USE="a52 aac acpi alsa branding cairo cdr dbus dts ..."

Diese Variable enthält bereits eine ganze Reihe von Schlüsselwörtern. Ändern Sie jedoch keine make.defaults-Datei, um die USE-Variable an Ihre persönlichen Bedürfnisse anzupassen: Änderungen in diesen Dateien werden rückgängig gemacht, wenn das Gentoo-Repositorium aktualisiert wird!

Um diese Standardeinstellung zu ändern fügen Sie der USE-Variable Schlüsselwörter hinzu oder entfernen sie daraus. Dies geschieht global durch Definition der USE-Variable in /etc/portage/make.conf. In dieser Variable können Sie die zusätzlich benötigten USE-Flags hinzufügen oder nicht mehr benötigte USE-Flags entfernen. Letzteres geschieht durch Voranstellen des Minuszeichens (-) vor das Schlüsselwort.

Um zum Beispiel die Unterstützung für KDE und Qt zu entfernen, aber die Unterstützung für LDAP hinzufügen, kann die folgende USE in /etc/portage/make.conf definiert werden:

DATEI /etc/portage/make.confUSE in make.conf aktualisieren

USE="-kde -qt5 ldap"

Deklaration von USE-Flags für einzelne Pakete

Manchmal wollen Benutzer ein bestimmtes USE-Flag für eine (oder mehrere) Anwendungen deklarieren, aber nicht systemweit. Um dies zu erreichen, bearbeiten Sie /etc/portage/package.use. package.use ist typischerweise eine einzelne Datei, kann aber auch eine Verzeichnis mit Unterdateien sein; siehe den Tipp unten und dann man 5 portage für weitere Informationen zur Verwendung dieser Konvention. Die folgenden Beispiele gehen davon aus, dass package.use eine einzelne Datei ist.

Zum Beispiel, um nur Blu-ray-Unterstützung für das VLC Media Player-Paket zu haben:

DATEI /etc/portage/package.useAktivieren der Blu-ray-Unterstützung für VLC

media-video/vlc bluray

Tipp
Wenn package.use bereits als Verzeichnis existiert (im Gegensatz zu einer einzeln Datei), können Pakete ihre USE-Flags ändern, indem sie einfach Dateien unter dem Verzeichnis package.use/ erstellen. Jede Dateinamenskonvention kann funktionieren, es ist jedoch ratsam, ein kohärentes Namensschema zu implementieren. Eine Konvention ist es, einfach den Paketnamen als Titel für die untergeordnete Datei zu verwenden. Das Setzen des bluray USE-Flags für das Paket media-video/vlc kann zum Beispiel wie folgt durchgeführt werden:

root #echo "media-video/vlc bluray" >> /etc/portage/package.use/vlc

In ähnlicher Weise ist es möglich, USE-Flags für eine bestimmte Anwendung explizit zu deaktivieren. Zum Beispiel, um die bzip2-Unterstützung in PHP zu deaktivieren (aber sie für alle anderen Pakete durch die USE-Flag-Deklaration in make.conf zu haben):

DATEI /etc/portage/package.useDeaktivieren der bzip2-Unterstützung für PHP

dev-lang/php -bzip2

Deklaration temporärer USE-Flags

Manchmal müssen Benutzer für einen kurzen Moment ein USE-Flag setzen. Anstatt /etc/portage/make.conf zweimal zu bearbeiten (um die USE-Änderungen vorzunehmen und rückgängig zu machen), deklarieren Sie einfach die USE-Variable als Umgebungsvariable. Denken Sie daran, dass diese Einstellung nur für den eingegebenen Befehl gilt; ein erneutes Aufrufen oder Aktualisieren dieser Anwendung (entweder explizit oder als Teil einer Systemaktualisierung) macht die Änderungen rückgängig, die durch die (temporäre) USE-Flag-Definition ausgelöst wurden.

Das folgende Beispiel entfernt, vorübergehend den Wert pulseaudio aus der USE-Variable, während der Installation von SeaMonkey:

root #USE="-pulseaudio" emerge www-client/seamonkey

Vorrang

Natürlich gibt es eine bestimmte Rangfolge, welche Einstellung Vorrang vor der USE-Einstellung hat. Der Vorrang für die USE-Einstellung ist, geordnet nach Priorität (die erste hat die niedrigste Priorität):

1. Standard-USE-Einstellung, deklariert in den make.defaults-Dateien, die Teil Ihres Profils sind
2. Benutzerdefinierte USE-Einstellungen in /etc/portage/make.conf
3. Benutzerdefinierte USE-Einstellung als Umgebungsvariable

Um die endgültige USE-Einstellung. wie sie von Portage gesehen wird, zu sehen, führen Sie emerge --info aus. Dies listet alle relevanten Variablen (einschließlich der USE-Variable) mit ihrer aktuellen, Portage bekannten Definition auf.

root #emerge --info

Anpassen des gesamten Systems an die neuen USE-Flags

Nachdem Sie die USE-Flags geändert haben, sollte das System aktualisiert werden, um die notwendigen Änderungen zu berücksichtigen. Verwenden Sie dazu die Option --newuse mit emerge:

root #emerge --update --deep --newuse @world

Als nächstes führen Sie Portage's depclean aus, um die bedingten Abhängigkeiten zu entfernen, die auf dem "alten" System entstanden sind, aber durch die neuen USE-Flags obsolet geworden sind.

Wichtig
Überprüfen Sie die mitgelieferte Liste der "veralteten" Pakete, um sicherzustellen, dass keine Pakete entfernt werden, die benötigt werden. Im folgenden Beispiel wird der Schalter --pretend (-p) verwendet, damit depclean die Pakete nur auflistet, ohne sie zu entfernen:

root #emerge --pretend --depclean

Wenn depclean beendet ist, kann emerge dazu auffordern die Anwendungen neu zu erstellen, die dynamisch gegen gemeinsam genutzte Objekte gelinkt sind, die von möglicherweise entfernten Paketen bereitgestellt werden. Portage bewahr notwendige Bibliotheken auf, bis diese Aktion durchgeführt wurde, um zu verhindern, dass Anwendungen zerstört werden. Es speichert, was neu erstellt werden muss, in der preserved-rebuild Menge. Um die notwendigen Pakete neu zu erstellen, führen Sie aus:

root #emerge @preserved-rebuild

Wenn dies alles erledigt ist, verwendet das System die neuen USE-Flag-Einstellungen.

Paketspezifische USE-Flags

Anzeige der verfügbaren USE-Flags

Nehmen wir das Beispiel von SeaMonkey: Auf welche USE-Flags hört es? Um das herauszufinden, verwenden wir emerge mit den Optionen --pretend und --verbose:

root #emerge --pretend --verbose www-client/seamonkey

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild  N     ] www-client/seamonkey-2.48_beta1::gentoo  USE="calendar chatzilla crypt dbus gmp-autoupdate ipc jemalloc pulseaudio roaming skia startup-notification -custom-cflags -custom-optimization -debug -gtk3 -jack -minimal (-neon) (-selinux) (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite {-test} -wifi" L10N="-ca -cs -de -en-GB -es-AR -es-ES -fi -fr -gl -hu -it -ja -lt -nb -nl -pl -pt-PT -ru -sk -sv -tr -uk -zh-CN -zh-TW" 216,860 KiB
 
Total: 1 package (1 new), Size of downloads: 216,860 KiB

emerge ist nicht das einzige Werkzeug für diese Aufgabe. Tatsächlich gibt es eine Werkzeug für Paketinformationen namens equery, das sich im Paket app-portage/gentoolkit befindet

root #emerge --ask app-portage/gentoolkit

Führen Sie nun equery mit dem Argument uses aus, um die USE-Flags eines bestimmten Pakets anzuzeigen. Zum Beispiel für das Paket app-portage/portage-utils:

user $equery --nocolor uses =app-portage/portage-utils-0.93.3

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-portage/portage-utils-0.93.3:
 U I
 + + nls       : Add Native Language Support (using gettext - GNU locale utilities)
 + + openmp    : Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE="openmp"
 + + qmanifest : Build qmanifest applet, this adds additional dependencies for GPG, OpenSSL and BLAKE2B hashing
 + + qtegrity  : Build qtegrity applet, this adds additional dependencies for OpenSSL
 - - static    : !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically

Erfüllung der REQUIRED_USE-Bedingungen

Einige Ebuilds erfordern oder verbieten bestimmte Kombinationen von USE-Flags, damit sie ordnungsgemäß funktionieren. Dies wird durch eine Reihe von Bedingungen ausgedrückt, die in einem REQUIRED_USE-Ausdruck enthalten sind. Diese Bedingungen stellen sicher, dass alle Funktionen und Abhängigkeiten vollständig sind und dass der Build erfolgreich ist und wie erwartet funktioniert. Wenn eine dieser Bedingungen nicht erfüllt ist, wird emerge Sie warnen und Sie auffordern, das Problem zu beheben.

Beispiel	Beschreibung
REQUIRED_USE="foo? ( bar )"	Wenn foo gesetzt ist, muss bar auch gesetzt sein.
REQUIRED_USE="foo? ( !bar )"	Wenn foo gesetzt ist, muss bar nicht gesetzt sein.
REQUIRED_USE="foo? ( || ( bar baz ) )"	Wenn foo gesetzt ist, muss bar oder baz gesetzt sein.
REQUIRED_USE="^^ ( foo bar baz )"	Genau eines von foo oder bar oder baz muss gesetzt sein.
REQUIRED_USE="|| ( foo bar baz )"	Mindestens eines von foo, bar oder baz muss gesetzt sein.
REQUIRED_USE="?? ( foo bar baz )"	Nicht mehr als eines von foo, bar oder baz darf gesetzt sein.

</noinclude>

Portage-Merkmale

Portage hat einige zusätzliche Funktionen, die das Gentoo-Erlebnis noch besser machen. Viele dieser Funktionen basieren auf bestimmten Software-Tools, die die Leistung, Zuverlässigkeit, Sicherheit, ... verbessern

Um bestimmte Portage-Funktionen zu aktivieren oder zu deaktivieren, editieren Sie /etc/portage/make.conf und aktualisieren oder setzen Sie die FEATURES-Variable, die die verschiedenen Funktionsschlüsselwörter, getrennt durch Leerzeichen, enthält. In einigen Fällen wird es auch notwendig sein, das zusätzliche Werkzeug zu installieren, auf dem die Funktion beruht.

Nicht alle Funktionen, die Portage unterstützt, sind hier aufgeführt. Für einen vollständigen Überblick konsultieren Sie bitte die make.conf Manpage:

user $man make.conf

Um herauszufinden, welche FEATURES standardmäßig gesetzt sind, führen Sie emerge --info aus und suchen Sie nach der Variable FEATURES oder grepen Sie sie heraus:

user $emerge --info | grep ^FEATURES=

Verteilte Kompilierung

Verwendung von distcc

distcc ist ein Programm zur Verteilung von Kompilierungen auf mehrere, nicht notwendigerweise identische, Rechner in einen Netzwerk. Der distcc-Client sendet alle notwendigen Informationen an die verfügbaren distcc-Server (auf denen distccd läuft), damit diese Teile des Quellcodes für den Client kompilieren können. Das Nettoergebnis ist eine schnellere Kompilierungszeit.

Mehr Informationen über distcc (und wie man es mit Gentoo zum Laufen bringt) finden Sie im Distcc-Artikel.

Installation von distcc

Distcc wird mit einem grafischen Monitor ausgeliefert, um Aufgaben zu überwachen, die der Computer zur Kompilierung wegschickt. Dieses Tool wird automatisch installiert, wenn gtk eingestellt ist.

root #emerge --ask sys-devel/distcc

Aktivieren der Portage distcc Unterstützung

Fügen Sie distcc zur FEATURES-Variable in /etc/portage/make.conf hinzu. Als nächstes bearbeiten Sie die Variable MAKEOPTS und erhöhen die Anzahl der parallelen Build-Jobs, die das System erlaubt. Eine bekannte Richtlinie ist es, -jN einzugeben, wobei N die Anzahl der CPUs ist, auf denen distccd läuft (einschließlich des aktuellen Hosts) plus eins, aber das ist nur eine Richtlinie.

Führen Sie nun distcc-config aus und geben Sie die Liste der verfügbaren distcc-Server ein. Für ein einfaches Beispiel nehmen wir an, dass die verfügbaren distcc-Server 192.168.1.102 (der aktuelle Host), 192.168.1.03 und 192.168.1.104 (zwei "entfernte" Hosts) sind:

root #distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Vergessen Sie nicht, auch den Daemon distccd zu starten:

root #rc-update add distccd default

root #/etc/init.d/distccd start

Zwischenspeicherung von Kompilierungsobjekten

Über ccache

ccache ist eine schneller Compiler-Cache. Immer wenn eine Anwendung kompiliert wird, werden Zwischenergebnisse zwischengespeichert, so dass die Kompilierungszeit bei jeder Neukompilierung desselben Programms und derselben Version stark reduziert wird. Das erste Mal, wenn ccache ausgeführt wird, ist es viel langsamer als eine normale Kompilierung. Nachfolgende Neukompilierungen sollten jedoch schneller sein. ccache ist nur hilfreich, wenn dieselbe Anwendungsversion viele Male neukompiliert wird; daher ist es meist nur für Softwareentwickler nützlich.

Für weitere Informationen über ccache besuchen Sie bitte die Homepage.

Warnung
ccache ist dafür bekannt, dass es zahlreiche Kompilierungsfehler verursacht. Manchmal behält ccache veraltete Codeobjekte oder beschädigte Dateien zurück, was dazu führen kann, dass Pakete nicht emerged werden können. Wenn dies passiert (Fehler wie "File not recognized: File truncated" erscheinen in den Build-Logs), versuchen Sie, die Anwendung mit deaktivierter ccache neu zu kompilieren (FEATURES="-ccache" in /etc/portage/make.conf oder einmalig von der Befehlszeile mit dem folgenden Befehl), bevor Sie einen Fehler melden:

root #FEATURES="-ccache" emerge --oneshot <kategorie/paket>

ccache Installieren

Um ccache zu installieren, führen Sie den folgenden Befehl aus:

root #emerge --ask dev-util/ccache

Aktivieren der Portage ccache Unterstützung

Öffnen Sie /etc/portage/make.conf und fügen Sie ccache zu allen Werten hinzu, die in der Variable FEATURES definiert sind. Wenn FEATURES nicht vorhanden ist, erstellen Sie sie. Als nächstes fügen Sie eine neue Variable namens CCACHE_SIZE hinzu und setzen sie auf 2G:

DATEI /etc/portage/make.confAktivieren der Portage ccache Unterstützung

FEATURES="ccache"
CCACHE_SIZE="2G"

Um zu überprüfen, ob ccache funktioniert, fordern Sie ccache auf, seine Statistiken bereitzustellen. Da Portage ein anderes ccache-Home-Verzeichnis verwendet, ist es notwendig, die Variable CCACHE_DIR vorübergehend zu setzen:

root #CCACHE_DIR="/var/tmp/ccache" ccache -s

Der Speicherort /var/tmp/portage ist das Standard-ccache-Home-Verzeichnis von Portage; es kann durch Setzen der Variable CCACHE_DIR in /etc/portage/make.conf geändert werden.

Wenn ccache eigenständig läuft, würde es den Standardspeicherort ${HOME}/.ccache/ verwenden, weshalb die CCACHE_DIR Variable gesetzt werden muss, wenn die (Portage) ccache Statistiken abgefragt werden.

Verwendung von ccache außerhalb von Portage

Um ccache für Nicht-Portage-Kompilierungen zu verwenden, fügen Sie /usr/lib/ccache/bin an den Anfang der PATH-Variable (vor /usr/bin). Dies kann durch Bearbeiten von ~/.bash_profile im Home-Verzeichnis des Benutzers erreicht werden. Die Verwendung von ~/.bash_profile ist eine Möglichkeit, PATH-Variablen zu definieren.

DATEI ~/.bash_profileSetzen des ccache-Speicherorts vor jedem anderen PATH

PATH="/usr/lib/ccache/bin:${PATH}"

Unterstützung von Binärpaketen

Vorgefertigte Pakete erstellen

Portage unterstützt die Installation von vorgefertigten Paketen. Auch wenn Gentoo selbst keine vorgefertigten Pakete anbietet, kann Portage vollständig auf vorgefertigte Pakete aufmerksam gemacht werden.

Um ein vorgefertigtes Paket zu erstellen, verwenden Sie den Befehl quickpkg, wenn das Paket bereits auf dem System installiert ist, oder emergen Sie mit den Optionen --buildpkg oder --buildpkgonly.

Um Portage zu veranlassen, vorgefertigte Pakete von jedem einzelnen Paket, das installiert wird, zu erstellen, fügen Sie buildpkg zur FEATURES-Variable hinzu.

Eine erweiterte Unterstützung für die Erstellung von vorgefertigten Paketsätzen kann mit Catalyst erhalten werden. Für weitere Informationen zu Catalyst lesen Sie bitte die Catalyst FAQ.

Installation von vorgefertigten Paketen

Obwohl Gentoo kein zentrales Repositorium anbietet, ist es jedoch möglich, ein zentrales Repositorium zu erstellen, in dem vorgefertigte Pakete gespeichert werden. Um dieses Repositorium zu verwenden, ist es notwendig, Portage darauf aufmerksam zu machen, indem die PORTAGE_BINHOST-Variable auf dieses verweist. Zum Beispiel, wenn die vorgefertigten Pakete auf ftp://buildhost/gentoo liegen:

DATEI /etc/portage/make.confPORTAGE_BINHOST Standard hinzufügen

PORTAGE_BINHOST="ftp://buildhost/gentoo"

Um ein vorgefertigtes Paket zu installieren fügen Sie dem emerge-Befehl die Option --getbinpkg neben der Option --usepkg hinzu. Erstere weist emerge an, das vorgefertigte Paket von dem zuvor definierten Server herunterzuladen, während letztere emerge auffordert, zuerst zu versuchen, das vorgefertigte Paket zu installieren, bevor es die Quellen abruft und kompiliert.

Zum Beispiel, um gnumeric mit vorgefertigten Paketen zu installieren:

root #emerge --usepkg --getbinpkg gnumeric

Weitere Informationen über die vorgefertigten Paketoptionen von emerge finden Sie in der emerge Manpage:

user $man emerge

Weitergabe von vorgefertigten Paketen an andere

Wenn vorgefertigte Pakete an andere weitergegeben werden sollen, stellen Sie sicher, dass dies erlaubt ist. Prüfen Sie dazu die Distributionsbedingungen des Upstream-Pakets. Für ein Paket, das unter der GNU GPL veröffentlicht wurde, müssen beispielsweise die Quellen zusammen mit den Binärdateien zur Verfügung gestellt werden.

Ebuilds können eine bindist-Beschränkung in ihrer RESTRICT-Variable definieren, wenn erstellte Binärdateien nicht verteilbar sind. Manchmal ist diese Einschränkung von einem oder mehreren USE-Flags abhängig.

Standardmäßig wird Portage keine Pakete aufgrund von Einschränkungen masken. Dies kann global durch Setzen der ACCEPT_RESTRICT-Variable geändert werden. Um zum Beispiel Pakete zu masken, die eine bindist-Beschränkung haben, fügen Sie die folgende Zeile in make.conf ein:

DATEI /etc/portage/make.confNur binär verteilbare Pakete akzeptieren

ACCEPT_RESTRICT="* -bindist"

Es ist auch möglich die ACCEPT_RESTRICT-Variable außer Kraft zu setzen, indem Sie die Option --accept-restrict an den Befehl emerge übergeben. Zum Beispiel wird --accept-restrict=bindist Pakete mit einer bindist-Beschränkung vorübergehend masken.

Denken Sie auch daran, die Variable ACCEPT_LICENSE zu setzen, wenn Sie Pakete verteilen. Siehe dazu den Lizenzabschnitt.

Wichtig
Es liegt in der Verantwortung jedes Benutzers, die Lizenzbedingungen der Pakete und die Gesetze des jeweiligen Landes einzuhalten. Die von Ebuilds definierten Metavariablen (RESTRICT oder LICENSE) können Hinweise geben, wenn die Verbreitung von Binärdateien nicht erlaubt ist, jedoch sind Ausgaben von Portage oder Fragen, die von Gentoo Entwicklern beantwortet werden, "keine" rechtlichen Aussagen und sollten nicht als solche betrachtet werden. Seien Sie vorsichtig und halten Sie sich an die Gesetze Ihres Standorts.

Abrufen von Dateien

Distfiles überprüfen

Um die Integrität zu überprüfen und (möglicherweise) zuvor entfernte/beschädigte Distfiles für alle derzeit installierten Pakete erneut herunterzuladen, führen Sie aus:

root #emerge --ask --fetchonly --emptytree @world

Wichtig
The contents of this page do not apply to users that chose a systemd profile in Choosing the right profile.

Runlevel

Booten des Systems

Wenn das System hochgefahren wird, wird viel Text eingeblendet. Wenn man genau hinschaut, wird man feststellen, dass dieser Text (normalerweise) bei jedem Neustart des Systems der gleiche ist. Die Abfolge all dieser Aktionen wird als Boot-Sequenz bezeichnet und ist (mehr oder weniger) statisch festgelegt.

Zunächst lädt der Bootloader das Kernel-Image, das in der Bootloader-Konfigurations definiert ist. Anschließend weist der Bootloader die CPU an, den Kernel auszuführen. Wenn der Kernel geladen und ausgeführt ist, initialisiert er alle kernelspezifischen Strukturen und Aufgaben und startet den init-Prozess.

Dieser Prozess stellt dann sicher, dass alle Dateisysteme (definiert in /etc/fstab) eingehängt und einsatzbereit sind. Dann führt er mehrere Skripte in /etc/init.d/ aus, die die Dienste starten, die für ein erfolgreich gebootetes System erforderlich sind.

Schließlich, wenn alle Skripte ausgeführt sind, aktiviert init die Terminals (in den meisten Fällen nur die virtuellen Konsolen, die unter Alt+F1, Alt+F2, etc. versteckt sind) und hängt einen spezifischen Prozess namens agetty daran. Dieser Prozess sorgt dafür, dass sich die Benutzer über diese Terminals anmelden können, indem er login ausführt.

Init-Skripts

Jetzt führt init die Skripte in /etc/init.d/ nicht mehr wahllos aus. Mehr noch, es führt nicht alle Skripte in /etc/init.d/ aus, sondern nur die Skripte, die es ausführen soll. Es entscheidet, welche Skripte es ausführt, indem es in /etc/runlevels/ nachschaut.

Zunächst führt init alle Skripte aus /etc/init.d/ aus, die symbolische Links innerhalb von /etc/runlevels/boot/ haben. Normalerweise werden die Skripte in alphabetischer Reihenfolge gestartet, aber einige Skripte enthalten Abhängigkeitsinformationen, die dem System mitteilen, dass ein anderes Skript ausgeführt werden muss, bevor sie gestartet werden können.

When all /etc/runlevels/boot/ referenced scripts are executed, init continues with running the scripts that have a symbolic link to them in /etc/runlevels/default/. Again, it will use the alphabetical order to decide what script to run first, unless a script has dependency information in it, in which case the order is changed to provide a valid start-up sequence. The latter is also the reason why commands used during the installation of Gentoo Linux used default, as in rc-update add sshd default.

Wie init funktioniert

Natürlich kann init das nicht alles selbst entscheiden. Es benötigt eine Konfigurationsdatei, die angibt, welche Aktionen durchgeführt müssen. Diese Konfigurationsdatei ist /etc/inittab.

Erinnern Sie sich an die soeben beschriebene Boot-Sequenz - die erste Aktion von init besteht darin, alle Dateisysteme einzuhängen. Dies ist in der folgenden Zeile aus /etc/inittab definiert:

DATEI /etc/inittabInitialisierungsbefehl

si::sysinit:/sbin/openrc sysinit

Diese Zeile sagt init, dass es /sbin/openrc sysinit ausführen muss, um das System zu initialisieren. Das Skript /sbin/openrc kümmert sich um die Initialisierung, so dass man sagen könnte, dass init nicht viel tut - es delegiert die Aufgabe der Initialisierung des Systems an einen anderen Prozess.

Second, init executed all scripts that had symbolic links in /etc/runlevels/boot/. This is defined in the following line:

DATEI /etc/inittabBoot command invocation

rc::bootwait:/sbin/openrc boot

Again the OpenRC script performs the necessary tasks. Note that the option given to OpenRC (boot) is the same as the sub-directory of /etc/runlevels/ that is used.

Now init checks its configuration file to see what runlevel it should run. To decide this, it reads the following line from /etc/inittab:

DATEI /etc/inittabDefault runlevel selection

id:3:initdefault:

In this case (which the majority of Gentoo users will use), the runlevel id is 3. Using this information, init checks what it must run to start runlevel 3:

DATEI /etc/inittabRunlevel definitions

l0:0:wait:/sbin/openrc shutdown
l1:S1:wait:/sbin/openrc single
l2:2:wait:/sbin/openrc nonetwork
l3:3:wait:/sbin/openrc default
l4:4:wait:/sbin/openrc default
l5:5:wait:/sbin/openrc default
l6:6:wait:/sbin/openrc reboot

The line that defines level 3, again, uses the openrc script to start the services (now with argument default). Again note that the argument of openrc is the same as the subdirectory from /etc/runlevels/.

When OpenRC has finished, init decides what virtual consoles it should activate and what commands need to be run at each console:

DATEI /etc/inittabTerminal definitions

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Available runlevels

In a previous section, we saw that init uses a numbering scheme to decide what runlevel it should activate. A runlevel is a state in which the system is running and contains a collection of scripts (runlevel scripts or initscripts) that must be executed when entering or leaving a runlevel.

In Gentoo, there are seven runlevels defined: three internal runlevels, and four user-defined runlevels. The internal runlevels are called sysinit, shutdown and reboot and do exactly what their names imply: initialize the system, powering off the system, and rebooting the system.

The user-defined runlevels are those with an accompanying /etc/runlevels/ subdirectory: boot, default, nonetwork and single. The boot runlevel starts all system-necessary services which all other runlevels use. The remaining three runlevels differ in what services they start: default is used for day-to-day operations, nonetwork is used in case no network connectivity is required, and single is used when the system needs to be fixed.

Working with initscripts

The scripts that the openrc process starts are called init scripts. Each script in /etc/init.d/ can be executed with the arguments start, stop, restart, zap, status, ineed, iuse, iwant, needsme, usesme, or wantsme.

To start, stop, or restart a service (and all depending services), the start, stop, and restart arguments should be used:

root #rc-service postfix start

Hinweis
Only the services that need the given service are stopped or restarted. The other depending services (those that use the service but don't need it) are left untouched.

To stop a service, but not the services that depend on it, use the --nodeps option together with the stop argument:

root #rc-service --nodeps postfix stop

To see what status a service has (started, stopped, ...) use the status argument:

root #rc-service postfix status

If the status information shows that the service is running, but in reality it is not, then reset the status information to "stopped" with the zap argument:

root #rc-service postfix zap

To also ask what dependencies the service has, use iwant, iuse or ineed. With ineed it is possible to see the services that are really necessary for the correct functioning of the service. iwant or iuse, on the other hand, shows the services that can be used by the service, but are not necessary for the correct functioning.

root #rc-service postfix ineed

Similarly, it is possible to ask what services require the service (needsme) or can use it (usesme or wantsme):

root #rc-service postfix needsme

Updating runlevels

rc-update

Gentoo's init system uses a dependency-tree to decide what service needs to be started first. As this is a tedious task that we wouldn't want our users to have to do manually, we have created tools that ease the administration of the runlevels and init scripts.

With rc-update it is possible to add and remove init scripts to a runlevel. The rc-update tool will then automatically ask the depscan.sh script to rebuild the dependency tree.

Adding and removing services

In earlier instructions, init scripts have already been added to the "default" runlevel. What "default" means has been explained earlier in this document. Next to the runlevel, the rc-update script requires a second argument that defines the action: add, del, or show.

To add or remove an init script, just give rc-update the add or del argument, followed by the init script and the runlevel. For instance:

root #rc-update del postfix default

The rc-update -v show command will show all the available init scripts and list at which runlevels they will execute:

root #rc-update -v show

It is also possible to run rc-update show (without -v) to just view enabled init scripts and their runlevels.

Configuring services

Why additional configuration is needed

Init scripts can be quite complex. It is therefore not really desirable to have the users edit the init script directly, as it would make it more error-prone. It is however important to be able to configure such a service. For instance, users might want to give more options to the service itself.

A second reason to have this configuration outside the init script is to be able to update the init scripts without the fear that the user's configuration changes will be undone.

conf.d directory

Gentoo provides an easy way to configure such a service: every init script that can be configured has a file in /etc/conf.d/. For instance, the apache2 initscript (called /etc/init.d/apache2) has a configuration file called /etc/conf.d/apache2, which can contain the options to give to the Apache 2 server when it is started:

DATEI /etc/conf.d/apache2Example options for apache2 init script

APACHE2_OPTS="-D PHP5"

Such a configuration file contains only variables (just like /etc/portage/make.conf does), making it very easy to configure services. It also allows us to provide more information about the variables (as comments).

Writing initscripts

Another useful resource is OpenRC's service script guide.

Is it necessary?

No, writing an init script is usually not necessary as Gentoo provides ready-to-use init scripts for all provided services. However, some users might have installed a service without using Portage, in which case they will most likely have to create an init script.

Do not use the init script provided by the service if it isn't explicitly written for Gentoo: Gentoo's init scripts are not compatible with the init scripts used by other distributions! That is, unless the other distribution is using OpenRC!

Layout

The basic layout of an init script is shown below.

CODE Example initscript layout (traditional)

#!/sbin/openrc-run
  
depend() {
#  (Dependency information)
}
  
start() {
#  (Commands necessary to start the service)
}
  
stop() {
#  (Commands necessary to stop the service)
}

CODE Example initscript layout (updated)

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="FooBar Daemon"
 
description="FooBar is a daemon that drinks"
extra_started_commands="drink"
description_drink="Opens mouth and reflexively swallows"
 
depend() {
#  (Dependency information)
}
 
start_pre() {
#  (Commands necessary to prepare to start the service)
    # Ensure that our dirs are correct
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commands necessary to clean up after the service)
    # Clean any spills
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

Every init script requires the start() function or command variable to be defined. All other sections are optional.

Dependencies

There are three dependency-alike settings that can be defined which influence the start-up or sequencing of init scripts: want, use and need. Next to these, there are also two order-influencing methods called before and after. These last two are no dependencies per se - they do not make the original init script fail if the selected one isn't scheduled to start (or fails to start).

• The use settings informs the init system that this script uses functionality offered by the selected script, but does not directly depend on it. A good example would be use logger or use dns. If those services are available, they will be put in good use, but if the system does not have a logger or DNS server the services will still work. If the services exist, then they are started before the script that uses them.
• The want setting is similar to use with one exception. use only considers services which were added to an init level. want will try to start any available service even if not added to an init level.
• The need setting is a hard dependency. It means that the script that is needing another script will not start before the other script is launched successfully. Also, if that other script is restarted, then this one will be restarted as well.
• When using before, then the given script is launched before the selected one if the selected one is part of the init level. So an init script xdm that defines before alsasound will start before the alsasound script, but only if alsasound is scheduled to start as well in the same init level. If alsasound is not scheduled to start too, then this particular setting has no effect and xdm will be started when the init system deems it most appropriate.
• Similarly, after informs the init system that the given script should be launched after the selected one if the selected one is part of the init level. If not, then the setting has no effect and the script will be launched by the init system when it deems it most appropriate.

It should be clear from the above that need is the only "true" dependency setting as it affects if the script will be started or not. All the others are merely pointers towards the init system to clarify in which order scripts can be (or should be) launched.

Now, look at many of Gentoo's available init scripts and notice that some have dependencies on things that are no init scripts. These "things" we call virtuals.

A virtual dependency is a dependency that a service provides, but that is not provided solely by that service. An init script can depend on a system logger, but there are many system loggers available (metalogd, syslog-ng, sysklogd, ...). As the script cannot need every single one of them (no sensible system has all these system loggers installed and running) we made sure that all these services provide a virtual dependency.

For instance, take a look at the postfix dependency information:

DATEI /etc/init.d/postfixDependency information of the postfix service

depend() {
  need net
  use logger dns
  provide mta
}

As can be seen, the postfix service:

• Requires the (virtual) net dependency (which is provided by, for instance, /etc/init.d/net.eth0).
• Uses the (virtual) logger dependency (which is provided by, for instance, /etc/init.d/syslog-ng).
• Uses the (virtual) dns dependency (which is provided by, for instance, /etc/init.d/named).
• Provides the (virtual) mta dependency (which is common for all mail servers).

Controlling the order

As described in the previous section, it is possible to tell the init system what order it should use for starting (or stopping) scripts. This ordering is handled both through the dependency settings use and need, but also through the order settings before and after. As we have described these earlier already, let's take a look at the portmap service as an example of such init script.

DATEI /etc/init.d/portmapDependency information of the portmap service

depend() {
  need net
  before inetd
  before xinetd
}

It is possible to use the "*" glob to catch all services in the same runlevel, although this isn't advisable.

CODE Using the * glob

depend() {
  before *
}

If the service must write to local disks, it should need localmount. If it places anything in /var/run/ such as a PID file, then it should start after bootmisc:

CODE Dependency setting with needing localmount and after bootmisc

depend() {
  need localmount
  after bootmisc
}

Standard functions

Next to the depend() functionality, it is also necessary to define the start() function. This one contains all the commands necessary to initialize the service. It is advisable to use the ebegin and eend functions to inform the user about what is happening:

CODE Example start() function

start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Do something in case a restart requires more than stop, start
  fi
  
  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Both --exec and --pidfile should be used in start and stop functions. If the service does not create a pidfile, then use --make-pidfile if possible, though it is recommended to test this to be sure. Otherwise, don't use pidfiles. It is also possible to add --quiet to the start-stop-daemon options, but this is not recommended unless the service is extremely verbose. Using --quiet may hinder debugging if the service fails to start.

Another notable setting used in the above example is to check the contents of the RC_CMD variable. Unlike the previous init script system, the newer OpenRC system does not support script-specific restart functionality. Instead, the script needs to check the contents of the RC_CMD variable to see if a function (be it start() or stop()) is called as part of a restart or not.

Hinweis
Make sure that --exec actually calls a service and not just a shell script that launches services and exits - that's what the init script is supposed to do.

For more examples of the start() function, please read the source code of the available init scripts in the /etc/init.d/ directory.

Another function that can (but does not have to) be defined is stop(). The init system is intelligent enough to fill in this function by itself if start-stop-daemon is used.

CODE Example stop() function

stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

If the service runs some other script (for example, Bash, Python, or Perl), and this script later changes names (for example, foo.py to foo), then it is necessary to add --name to start-stop-daemon. This must specify the name that the script will be changed to. In this example, a service starts foo.py, which changes names to foo:

CODE Example definition for a service that starts the foo script

start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

start-stop-daemon has an excellent man page available if more information is needed:

user $man start-stop-daemon

Gentoo's init script syntax is based on the POSIX Shell so people are free to use sh-compatible constructs inside their init scripts. Keep other constructs, like bash-specific ones, out of the init scripts to ensure that the scripts remain functional regardless of the change Gentoo might do on its init system.

Adding custom options

If the initscript needs to support more options than the ones we have already encountered, then add the option to one of the following variables, and create a function with the same name as the option. For instance, to support an option called restartdelay:

• extra_commands - Command is available with the service in any state
• extra_started_commands - Command is available when the service is started
• extra_stopped_commands - Command is available when the service is stopped

CODE Example definition of restartdelay method

extra_started_commands="restartdelay"
  
restartdelay() {
  stop
  sleep 3    # Wait 3 seconds before starting again
  start
}

Wichtig
The restart() function cannot be overridden in OpenRC!

Service configuration variables

In order to support configuration files in /etc/conf.d/, no specifics need to be implemented: when the init script is executed, the following files are automatically sourced (i.e. the variables are available to use):

• /etc/conf.d/YOUR_INIT_SCRIPT
• /etc/conf.d/basic
• /etc/rc.conf

Also, if the init script provides a virtual dependency (such as net), the file associated with that dependency (such as /etc/conf.d/net) will be sourced too.

Changing runlevel behavior

Who might benefit

Many laptop users know the situation: at home they need to start net.eth0, but they don't want to start net.eth0 while on the road (as there is no network available). With Gentoo the runlevel behavior can be altered at will.

For instance, a second "default" runlevel can be created which can be booted that has other init scripts assigned to it. At boot time, the user can then select what default runlevel to use.

Using softlevel

First of all, create the runlevel directory for the second "default" runlevel. As an example we create the offline runlevel:

root #mkdir /etc/runlevels/offline

Add the necessary init scripts to the newly created runlevel. For instance, to have an exact copy of the current default runlevel but without net.eth0:

root #cd /etc/runlevels/default

root #for service in *; do rc-update add $service offline; done

root #rc-update del net.eth0 offline

root #rc-update show offline

(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Even though net.eth0 has been removed from the offline runlevel, udev might want to attempt to start any devices it detects and launch the appropriate services, a functionality that is called hotplugging. By default, Gentoo does not enable hotplugging.

To enable hotplugging, but only for a selected set of scripts, use the rc_hotplug variable in /etc/rc.conf:

DATEI /etc/rc.confEnable hotplugging of the WLAN interface

rc_hotplug="net.wlan !net.*"

Hinweis
For more information on device initiated services, please see the comments inside /etc/rc.conf.

Edit the bootloader configuration and add a new entry for the offline runlevel. In that entry, add softlevel=offline as a boot parameter.

Using bootlevel

Using bootlevel is completely analogous to softlevel. The only difference here is that a second "boot" runlevel is defined instead of a second "default" runlevel.

Umgebungsvariablen

Einleitung

Eine Umgebungsvariable ist ein benanntes Objekt, das Informationen enthält, die von einer oder mehreren Anwendungen verwendet werden. Durch die Verwendung von Umgebungsvariablen kann man auf einfache Weise eine Konfigurationseinstellung für eine oder mehrere Anwendungen ändern.

Wichtige Beispiele

Die folgende Tabelle enthält eine Reihe von Variablen, die von einem Linux-System verwendet werden, und beschreibt ihre Verwendung. Im Anschluss an die Tabelle sind Beispielwerte aufgeführt.

Variable	Description
PATH	This variable contains a colon-separated list of directories in which the system looks for executable files. If a name is entered of an executable (such as ls, rc-update, or emerge) but this executable is not located in a listed directory, then the system will not execute it (unless the full path is entered as the command, such as /bin/ls).
ROOTPATH	This variable has the same function as PATH, but this one only lists the directories that should be checked when the root-user enters a command.
LDPATH	This variable contains a colon-separated list of directories which the dynamic linker searches to find a library.
MANPATH	This variable contains a colon-separated list of directories which the man(1) command searches for man pages.
INFODIR	This variable contains a colon-separated list of directories which the info(1) command searches for info pages.
PAGER	This variable contains the path to the program used to list the contents of files (such as less or more(1)).
EDITOR	This variable contains the path to the program used to edit files (such as nano or vi).
KDEDIRS	This variable contains a colon-separated list of directories which contain KDE-specific material.
CONFIG_PROTECT	This variable contains a space-delimited list of directories which should be protected by Portage during package updates.
CONFIG_PROTECT_MASK	This variable contains a space-delimited list of directories which should not be protected by Portage during package updates.

Nachstehend finden Sie ein Beispiel für die Definition all dieser Variablen:

CODE Example settings for the mentioned variables

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
# Directories that are protected during package updates.
# Note the use of the \ (backslashes) on the end of the following lines which interprets to a single space-delimited line.
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
# Directories that are _not_ protected during package updates.
CONFIG_PROTECT_MASK="/etc/gconf"

Globale Definition von Variablen

Das env.d-Verzeichnis

Um die Definition dieser Variablen zu zentralisieren, hat Gentoo das Verzeichnis /etc/env.d/ eingeführt. Innerhalb dieses Verzeichnisses gibt es eine Reihe von Dateien, wie z.B. 00basic, 05gcc, usw., die die Variablen enthalten, die von der im Namen genannten Anwendung benötigt werden.

Wenn z.B. gcc installiert wird, wurde eine Datei namens 05gcc vom Ebuild erstellt, die die Definition der folgenden Variablen enthält:

DATEI /etc/env.d/gcc/config-x86_64-pc-linux-gnuDefault gcc enabled environment variables for GCC 13

GCC_PATH="/usr/x86_64-pc-linux-gnu/gcc-bin/13"
LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/13:/usr/lib/gcc/x86_64-pc-linux-gnu/13/32"
MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man"
INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info"
STDCXX_INCDIR="g++-v13"
CTARGET="x86_64-pc-linux-gnu"
GCC_SPECS=""
MULTIOSDIRS="../lib64:../lib"

Other distributions might tell the system administrator to change or add such environment variable definitions in /etc/profile or other locations. Gentoo on the other hand makes it easy for the sysadmins (and for Portage) to maintain and manage the environment variables without having to pay attention to the numerous files that can contain environment variables.

For instance, when gcc is updated, the associated file(s) under /etc/env.d/gcc are updated too without requesting any administrative interaction.

There are still occasions where a system administrator is asked to set a certain environment variable system-wide. As an example, take the http_proxy variable. Instead of editing a file under the /etc/profile directory, create a file named /etc/env.d/99local and enter the definition in it:

DATEI /etc/env.d/99localSetting a global environment variable

http_proxy="proxy.server.com:8080"

By using the same file for all customized environment variables, system administrators have a quick overview on the variables they have defined themselves.

env-update

Several files within the /etc/env.d directory add definitions to the PATH variable. This is not a mistake: when the env-update command is executed, it will append the several definitions before it atomically updates each environment variable, thereby making it easy for packages (or system administrators) to add their own environment variable settings without interfering with the already existing values.

The env-update script will append the values in the alphabetical order of the /etc/env.d/ files. The file names must begin with two decimal digits.

CODE Update order used by env-update

09sandbox    50baselayout     51dconf
     +------------+----------------+-----------+
CONFIG_PROTECT_MASK="/etc/sandbox.d /etc/gentoo-release /etc/dconf ..."

The concatenation of variables does not always happen, only with the following variables: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH, and PYTHONPATH. For all other variables the latest defined value (in alphabetical order of the files in /etc/env.d/) is used.

It is possible to add more variables into this list of concatenate-variables by adding the variable name to either COLON_SEPARATED or SPACE_SEPARATED variables (also inside an /etc/env.d/ file).

When executing env-update, the script will create all environment variables and place them in /etc/profile.env (which is used by /etc/profile). It will also extract the information from the LDPATH variable and use that to create /etc/ld.so.conf. After this, it will run ldconfig to recreate the /etc/ld.so.cache file used by the dynamical linker.

To notice the effect of env-update immediately after running it, execute the following command to update the environment. Users who have installed Gentoo themselves will probably remember this from the installation instructions:

root #env-update && source /etc/profile

Hinweis
The above command only updates the variables in the current terminal, new consoles, and their children. Thus, if the user is working in X11, he needs to either type source /etc/profile in every new terminal opened or restart X so that all new terminals source the new variables. If a login manager is used, it is necessary to become root and restart the /etc/init.d/xdm service.

Wichtig
It is not possible to use shell variables when defining other variables. This means things like FOO="$BAR" (where $BAR is another variable) are forbidden.

Defining variables locally

User specific

It might not be necessary to define an environment variable globally. For instance, one might want to add /home/my_user/bin and the current working directory (the directory the user is in) to the PATH variable but not want all other users on the system to have those directories in their PATH. To define an environment variable locally, use ~/.bashrc (for all interactive shell sessions) or ~/.bash_profile (for login shell sessions):

DATEI ~/.bashrcExtending PATH for local usage

# A colon followed by no directory is treated as the current working directory
PATH="${PATH}:/home/my_user/bin:"

After logout/login, the PATH variable will be updated.

Session specific

Sometimes even stricter definitions are required. For instance, a user might want to be able to use binaries from a temporary directory without needing to use the full path to the binaries and without needing to temporarily change ~/.bashrc.

In this case, just define the PATH variable in the current session by using the export command. As long as the user does not log out, the PATH variable will be using the temporary settings.

root #export PATH="${PATH}:/home/my_user/tmp/usr/bin"