Handbuch:Parts/Arbeit/Portage
Bitte versuchen Sie nicht, den Anweisungen aus dem Handbook:Parts Namespace (DIESE SEITE) oder den Unterseiten zu folgen. Handbook:Parts ist ein Meta-Handbuch, um Text über Transklusion in andere Handbücher einzufügen. Bitte verwenden Sie die Architektur-spezifischen Handbücher für eine vollständige Installations-Anleitung.
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 emergeGentoo-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 --syncManchmal 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-webrsyncWartung 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 pdfUm auch die Beschreibung zu durchsuchen, verwenden Sie die Option --searchdesc (oder -S):
user $emerge --searchdesc pdfBeachten Sie, dass die Ausgabe eine Vielzahl von Informationen liefert. Die Felder sind eindeutig beschriftet, so dass wir nicht weiter auf ihre Bedeutung eingehen werden:
* 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/gnumericDa 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 gnumericUm 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 gnumericWä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 gnumericDokumentation 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-libThese 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.3total 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 gnumericWenn 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 @worldDer 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 @worldMetapakete
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.
{{{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:
/etc/portage/make.confDie Standardeinstellung von ACCEPT_LICENSEACCEPT_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:
/etc/portage/package.licenseAkzeptieren der google-chrome-Lizenz für das google-chrome Paketwww-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:
/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
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:
/etc/portage/make.confAlle Lizenzen außer EULAs akzeptierenlang=bashACCEPT_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
[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
!!! all ebuilds that could satisfy "bootsplash" have been masked.
!!! 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
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:
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
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
[ 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
!!! 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
!!! 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
!!! 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
>>> 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.
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.