eix

Section: (1)
Updated:
Page Index

---

 

NAME

eix - Programme zum Durchsuchen, Vergleichen und Updaten eines Binärcaches der lokalen Portagebaums

 

ÜBERSICHT

eix [gemeinsame Optionen] [OPTIONEN] AUSDRUCK

eix-update [gemeinsame Optionen] [eix-update-OPTIONEN]

eix-diff [gemeinsame Optionen] [ALTER-CACHE] [NEUER-CACHE]

eix-sync

eix-postsync

eix-test-obsolete

eix-remote

eix-layman

eix-installed-after

eix-installed

eix-etcat

eix-functions.sh

eix-header

eix-drop-permissions [--] [Befehl zum Ausführen]

masked-packages Kategorie/Name-Version[:Slot][::Repo]

versionsort [-n|-p|-f|-v|-r|-V] [(Müll)Paket-]Version ...

 

BESCHREIBUNG

eix-update generiert einen Binärcache des lokalen Portagebaums und von Overlays. eix durchsucht diesen Cache nach Paketen, die Kriterien erfüllen, die durch AUSDRUCK festgelegt werden; falls auf der Kommandozeile kein einschränkendes Kriterium angegeben wird, werden natürlich alle Pakete ausgegeben. eix-diff vergleicht zwei solcher Binärcache und gibt Pakete aus, die hinzugefügt oder entfernt wurden, oder für die sich die höchste stabile Versionsnummer geändert hat.

Alle zugehörigen Programme und Skripte lesen die später beschrieben Konfigurationsfiles. eix-sync hat optional eine separate Konfigurations-Datei.

eix-sync kann den Portage/Overlay-Baum syncen und vergleicht ihn mit dem alten Cache (vermöge eix-diff). Mehr über eix-sync erfahren Sie durch den Aufruf eix-sync -h und in der untenstehenden Beschreibung von /etc/eix-sync.conf. Beachten Sie, dass der Inhalt dieser Datei auch in der Variablen EIX_SYNC_CONF gespeichert werden kann.

eix-postsync ist eine einfache Alternative zu eix-sync. Es ist ähnlich wie eix-update, erzeugt aber zuvor ein Backup der Cache-Datei, so dass eix-diff benutzt werden kann, um die Unterschiede zum vorherigen Syncen zu zeigen. Um eix-postsync automatisch nach <emerge --sync> aufzurufen, kann man für >=portage-2.3.7 das Verzeichnis /etc/portage/postsync.d/ erzeugen und dort einen symbolischen Link auf eix-postsync platzieren. Der Hauptnachteil von emerge --sync mit diesem Link (im Vergleich zu eix-sync) ist, dass für den Ausnahmefall, dass ein Upgrade von eix die alte Datenbank nicht mehr unterstützt, eix-diff für das erste Syncen nach dem Upgrade nicht funktioniert (außer man ruft manuell eix-update vor dem Syncen auf).

eix-test-obsolete ist ein Skript, das eix mehrmals aufruft, um die Ausgabe von eix -tTc besser organisiert auszugeben.

eix-remote kann eine Eix-Datenbank von einem externen Server syncen und ihn zum lokalen Cache hinzufügen und wieder entfernen. Falls nicht anders konfiguriert, benutzt es ein separates Datenbankfile. Bei dieser Vorgabe sollten Sie regelmäig eix-remote add1 und/oder <eix-remote add2> nach <eix-update> aufrufen, so dass das separate Cachefile mit der Hauptdatenbank synchron ist. (Bei Benutzung von eix-sync geschieht dies per Default.) Falls das selbe Datenbankfile benutzt wird, können Remote-Daten über eix-update-Aufrufe hinweg erhalten werden, wenn Sie KEEP_VIRTUALS=true in /etc/eixrc setzen. Per Standardeinstellung wird dieses Skript seine Rechte durch eix-drop-permissions fallenlassen. Mehr zu eix-remote erfahren Sie durch den Aufruf eix-remote -h.

eix-installed-after ist ein einfaches Skript (mit vielen Kommentaren), das einige Möglichkeiten aufzeigt, wie eine vom Skript angepasste eix-Ausgabe genutzt werden kann: Das Skript gibt diejenigen Pakete aus, die nach (oder vor) dem letzten (oder ersten) Emerge eines spezifizierten Pakets/Version installiert wurden. Mehr zur Benutzung erfahren Sie durch den Aufruf eix-installed-after -h.

eix-layman kann lokale Layman-Overlays zur aktuellen Datenbank hinzufügen. Dies kann hilfreich sein, wenn man es vermeiden will, Layman-Overlays zu den regulären portage-Repositories hinzuzufügen. Mehr zu eix-lamyan erfahren Sie durch den Aufruf eix-layman -h. eix-layman versteht sich auch als Beispielskript, wie eix-functions.sh genutzt werden kann:

eix-functions.sh gibt Hilfsfunktionen aus, die von eix-sync, eix-remote, und eix-layman benutzt werden und die in ähnlichen Skripten benutzt werden können. Man sollte die Ausgabe des Programms mit "eval" verarbeiten. Beachten Sie, dass unmittelbar danach normalerweise zur Initialisierung ReadFunctions aufgerufen werden muss.

eix-header ist ein Hilfsprogramm für eix-remote (und möglicherweise eigene Skripte). Es kann Datenbankdatei-Köpfe überprüfen und Overlay-Pfade oder -Labels aus diesen Dateien finden oder ausgeben. Eine detailliertere Beschreibung erhalten Sie mit eix-header -h.

eix-drop-permissions ist ein Hilfsprogramm für eix-remote (und möglicherweise eigene Skripte). Es führt das im Argument angegebene Kommando mit eingeschränkten Rechten aus. Die Einschränkung wird durch EIX_USER, EIX_GROUP, EIX_UID, EIX_GID (siehe später) spezifiziert. Beachten Sie, dass auch die Binärprogramme eix, eix-diff und eix-update ihre Rechte so früh wie möglich gemäß diesen Variablen einschränken, d.h. es kann nötig sein, diese Variablen anzupassen, falls eix (insbesondere eix-update) in einem Nichtstandard-Setting genutzt werden soll.

eix-installed ist ein einfaches Skript, das alle installierten Pakete (und ihre exakte Version) ausgibt, und das prüfen kann, welche Pakete mit/ohne Repository- oder Buildtime-Information gebaut wurden (vgl. die Beschreibung zu CHECK_INSTALLED_OVERLAYS und USE_BUILD_TIME). Mehr zu eix-installed erfahren Sie durch den Aufruf eix-installed -h.

eix-etcat ist ein Wrapper-Skripts, das eix mit einer Konfiguration aufruft, so dass das Verhalten ähnlich dem von etcat -v aus alten app-portage/gentoolkit Versionen oder dessen aktuelle Version von https://github.com/proteusx/etcat/ (z.B. app-portage/etcat aus dem mv overlay) ist. Die Ausgabe ist analog, und die voreingestellte Eingabe akzeptiert eine Folge von Paketnamen (die Angabe der Kategorie ist optional). Es kann lehrreich sein, sich das einfache Wrapper-Skript anzusehen, wenn man ein eigenes Eingabe-/Ausgabeformat schreiben will: Das Ausgabeformat erhält man durch den Aufruf von eix --print FORMAT_ETCAT und eix --print FORMAT_VERSION_ETCAT.

masked-packages ist ein Hilfsprogramm für Skripte, das die Argumente gegen eine Maskenliste testet. Details stehen nahe am Ende dieser Manpage.

versionsort ist ein Hilfsprogramm für Skripte, das die Versionsnummer von den Argumenten abtrennt, und das die gefundenen Versionsnummern gemäß den Portage-Regeln sortiert. Details stehen nahe am Ende dieser Manpage.

 

OPTIMIERUNG, SPEICHER, SICHERHEIT

Wenn Sie eix vom gentoo repository installiert haben, dann wird das eix ebuild sehr wahrscheinlich nicht die CXXFLAGS und LDFLAGS benutzt haben, die der Maintainer von eix zur Optimierung und Sicherheit empfiehlt. Zudem kann eix bei Bedarf so konfiguriert werden, dass es weniger Speicher benötigt. Lesen Sie daher bitte den Abschnitt INSTALLATION, um zu erfahren, wie der Maintainer von eix die Installation empfiehlt.

 

BEISPIELE

Die folgenden Beispiele sind nützliche aber vielleicht untypische Anwendungen von eix. Sie werden hier aufgelistet, um eine Idee davon zu geben, welche unerwarteten Dinge mit eix mit möglich sind. Da diese Beispiele mit cut-and-paste von dieser Seite kopiert werden sollten, sind sie gleich zu Anfang aufgelistet. Um zu verstehen, wie sie funktionieren, ist es natürlich notwendig, die vollständige Manpage zu lesen. Weitere Beispiele finden Sie beispielsweise im Skript eix-installed-after, das viele Kommentare enthält.

cmd | eix '-|*' --format '<markedversions:NAMESLOT>'

Falls cmd eine Liste der Gestalt Kategorie/Name-Version or =Kategorie/Name-Version
 ausgibt, gibt das obige Kommando die entsprechende List Kategorie/Name oder Kategorie/Name:SLOT aus (je nachdem, ob die SLOTs unterschieden werden müssen).

cmd | eix '-|*' --format '<markedversions:NAMEASLOT>'

Ähnlich wie eben, aber es wird immer Kategorie/Name:SLOT ausgeben, selbst wenn SLOT redundant ist. (Mnemonic: Always).

eix '-I*' --format '<installedversions:NAMEVERSION>'

Gibt die installierten Pakete im Format Kategorie/Name-Version aus. Natürlich kann man NAMEVERSION auch durch NAMESLOT oder NAMEASLOT ersetzen, um ein anderes Format zu erhalten. Der einzige Zweck der Option I in diesem Zusammenhang ist eine geringfügige Beschleunigung der Ausgabe.

eix '-I*' --format '<installedversions:EQNAMEVERSION>'

Ähnlich wie eben, aber im Format =Kategorie/Name-Version, das direkt von Portage benutzt werden kann.

eix '-I*' --format '<installedversions:DATESORT>' | sort -n | cut -f2-3

Gibt die installierten Pakete (falls notwendig mit Slots) aus, sortiert nach Installationsdatum. Zur Ausgabe in einem anderen Format kann DATESORT entsprechend modifiziert werden (die ursprüngliche Definition steht in der Ausgabe von eix --dump).

Das Sortieren funktioniert folgendermaßen: Die DATESORT-Variable gibt als erste Spalte die Sekunden seit Epoch aus (Mit eix --print DATESORT erfahren Sie, dass dies durch die Variable DATESORT_DATE geschieht, deren erster Eintrag %s lautet), und sort erzeugt so durch einfaches alphabetisches Sortieren die korrekte Ordnung. Das cut-Kommando verschluckt schließlich wieder die erste Spalte, die nur zum Sortieren benötigt wurde.

In diesen Beispielen sind Dinge wie NAMEVERSION oder DATESORT nur Variablennamen, die in eix vordefiniert wurden (eix --dump listet sie auf). Genausogut können natürlich auch eigene Variablen definiert und benutzt werden. Genaueres dazu steht später in der Manpage, insbesonder die Beschreibung des FORMAT Strings.

 

OPTIONEN

 

gemeinsame Optionen

Die folgenden Optionen sind eix, eix-diff und eix-update gemein:

-h, --help

Ausgabe eines Hilfstextes und Ende.

-Q, --quick (toggle) (nicht für eix-update)

Verhindert/Ermöglicht, dass Slots installierter Versionen gelesen werden, die nicht vermutet werden können (d.h. installierter Versionen von Paketen mit mindestens zwei verschiedene Slots, für die die installierte Version nicht mehr in der Datenbank ist). Beachten Sie, dass mit dieser Option eix und eix-diff falsche Posittreffer über Up-/Downgrade-Empfehlungen für diese Pakete ausgeben könnten.

--care (nicht für eix-update)

Deaktiviert --quick, und darüberhinaus werden Slots installierter Versionen immer gelesen, auch dann wenn der Slotname vermutet werden kann. Dies stellt insbesondere sicher, dass Up-/Downgrade-Empfehungen auch dann ausgegben werden, wenn sich der Slotname einer installierten Version ändert. Beachten Sie, dass diese Option die Geschwindigkeit beim ersten Aufruf dramatisch reduziert. (Wenn das Dateisystem einen vernünftigen Cache hat, werden spätere Aufrufe kaum langsamer sein als ohne diese Option).

--deps-installed (nicht für eix-update)

Dies ist das selbe wie DEPS_INSTALLED=true. Abhängigkeiten installierter Versionen werden immer gelesen, auch dann, wenn sie von verfügbaren Versionen bekannt ist. Beachten Sie, dass diese Option die Geschwindigkeit beim ersten Aufruf dramatisch reduziert. (Wenn das Dateisystem einen vernünftigen Cache hat, werden spätere Aufrufe kaum langsamer sein als ohne diese Option).

-q, --quiet (toggle)

Ausgaben auf stdout werden verhindert. Für eix kann ggf. die Ausführungszeit weiter reduziert werden, wenn diese Kombination mit (je nach Einsatzzweck) entweder --brief oder --brief2 kombiniert wird, und durch Setzen von COUNT_ONLY_PRINTED=false. Siehe auch NOFOUND_STATUS und MOREFOUND_STATUS

--dump

Ausgabe der aktuellen eixrc-Variablen und ihrer Vorgabewerte als Kommentar; dann Ende.

--dump-defaults

Ausgabe der Vorgabewerte der eixrc-Variablen und ihrer aktuellen Werte als Kommentar; dann Ende.

--print VAR

Ausgabe der spezifizierten Variablen VAR aus eixrc oder der Portage-Konfiguration; dann Ende. Die Ausgabe erfolgt vollständig expandiert, so wie sie intern von eix benutzt würde. Der Exit-Status ist positiv, falls VAR eix unbekannt ist (siehe --known-vars). Diese Option ist hauptsächlich für Skripte nützlich oder zum Debuggen. Zur Benutzung in Skripten empfiehlt sich die Benutzung von PRINT_APPEND. um das Abschneiden von Leerzeichen am Ende zu verhinden (siehe die Beschreibung zu PRINT_APPEND). Ein spezieller VAR-Wert, der nur auf diese Weise erhalten werden kann, ist USE.profile was den USE-String des Profiles enthält.

--known-vars

Ausgabe eine alphabetischen Liste aller Variablen, die eix für --print bekannt sind. Nach jedem Variablennamen wird ein Zeilenumbruch ausgegeben.

-V, --version

Ausgabe der Versionsnummer und Ende.

-n, --nocolor

Verhindert die Ausgabe von ANSI Farbcodes; nützlich für Terminals, die diese nicht kennen. (Dies wird automatisch aktiv, falls stdout nicht auf ein tty führt, kann aber mit --force-color überschrieben werden).

-F, --force-color

Das Gegenteil von --nocolor.

 

Spezielle Informations-Optionen

Die folgenden speziellen Informations-Optionen versteht nur das eigentliche eix-Programm. Sie sind einmalig und ausschließend, d.h. eix gibt nur die entsprechenden Daten aus und beendet sich dann.

--ansi (auch für eix-diff)

Legt die 256-Farbpalette von Todd Larason fest (dem Author des 256-Farbsupports für xterm). Benutzen Sie diese Option, wenn ein Tool die normalerweise eingestellte Palette umdefiniert hat.

--256, --256f, --256f0, --256f1, 256b

Print the 256 color palettes (assuming it follows ansi color scheme) and exit. With --256d/--256l (--256d0/--256l0, --256d1/--256l1) only the foreground palettes with dark/light background (or only the normal or bright dark/light foreground palette, respectively) is printed. With --256b only the background palette is printed. --256, --256f, --256f0, --256f1, 256b Ausgabe der 256-Farben-Paletten unter der Annahme, dass sie dem Ansi-Farbschema folgt; danach Programmende. Mit --256d/--256l (--256d0/--256l0, --256d1/--256l1) werden nur die Vordergrund-Farbpaletten mit dunklem/hellem Hintergrund ausgegeben (bzw. nur die normale oder fette Vordergrund-Farbpalette mit dunklem/hellen Hintergrund). Mit --256b wird nur die Hintergrundfarbpalette ausgegeben.

--print-all-eapis

Gibt alle IUSE- oder EAPIs aus, die in irgendeiner Version benutzt werden.

--print-all-useflags

Gibt alle IUSE- oder REQUIRED_USE-Worte aus, die in irgendeiner Version benutzt werden.

--print-all-keywords

Gibt alle KEYWORDS aus, die in irgendeiner Version benutzt werden.

--print-all-slots

Gibt alle SLOT-Strings aus, die in irgendeiner Version benutzt werden.

--print-all-licenses

Gibt alle LICENSE-Strings aus, die in irgendeiner Version benutzt werden.

--print-all-depends

Gibt alle Worte aus, die in einem {,R,P,B}DEPEND auftauchen. Dies geht nur, falls DEP=true aktiv ist (und bei der Erzeugung der Cachedatei aktiv war).

--print-world-sets

Gibt die world sets aus.

--print-profile-paths

Gibt alle Pfade des aktuellen Profils aus. An jeden Pfad wird PRINT_APPEND angehängt. Falls PRINT_APPEND leer ist, wird das Nullzeichen angehängt.

 

Ausgabe-Optionen

--nowarn (toggle)

Unterdrückt einige Warnungen bzgl. der Portage-Konfiguration

-x, --versionsort (toggle)

Gibt die vorhandenen Versionen sortiert nach Versionen (oder Slots) aus. Bei Slot-sortierter Ausgabe wird jeder Slot in einer neuen Zeile ausgegeben. Dieser Modus kann mit --versionlines (-l) kombiniert werden, um für jede neue Version eine neue Zeile auszugeben.

-l, --versionlines (toggle)

Gibt die vorhandenen Versionen in einer (vertikalen) Liste aus. Nur in diesem Modus werden gewisse Zusatzinformationen für jede Version ausgegeben. Genauer, je nachdem ob --verbose benutzt wird und abhängig vom Status der Konfigurationsvariablen VERSION_{IUSE,KEYWORDS,DEPS}_{NORMAL,VERBOSE} kann dies KEYWORDS, IUSE, DEPEND, RDEPEND, PDEPEND, BDEPEND sein. Beachten Sie: Falls IUSE nicht für jede Version ausgegeben wird, so wird es nur gesammelt für das gesamte Paket ausgegeben, was einen falschen Eindruck geben kann, da sich IUSE von Version zu Version zuweilen dramatisch ändert.

-c, --compact

Wählt ein kompaktes Layout für die Ausgabe von Suchergebnissen. Nützlich, um einen besseren Überblick über eine lange Ergebnisliste zu erhalten, und es hilft auch, die Suche über eine lansame Verbindung (wie etwa eine serielle Konsole) zu beschleunigen.

-v, --verbose

Benutzt ein ausführliches Layout mit zusätzlichen Informationen über Suchergebnisse (wie etwa die Lizenz eines Pakets).

-N, --normal

Benutzt das normale Layout, das der Default ist, wenn DEFAULT_FORMAT nicht ausdrücklich anders gesetzt wurde.

--xml (toggle)

Ausgabe im XML format. Falls dies für ein externes Programm geschieht, empfiehlt sich zusätzlich die Benutzung von --care und das Exportieren einiger Variablen wie LOCAL_PORTAGE_CONFIG, so dass Benutzereinstellungen die Ausgabe nicht beeinflussen. Mit dieser option werden OVERLAYS_LIST=none und --pure-packages automatisch aktiviert. Das Ausgabeformat kann minimal mit den XML_*-Variablen beeinflusst werden. Das benutzte XML-Format ist auf menschenlesbare Art in den Dateien eix-xml.html oder eix-xml.txt dokumentiert und auf weniger menschenlesbare Art (nämlich als XML-Schema) in der Datei eix-xml.xsd

-*, --pure-packages (toggle)

(bei der Benutzung der Kurzform in einer Shell bitte das Quoten nicht vergessen!) Diese Option verhindert die Ausgabe zusätzlicher Informationen (Overlaynamen, Zahl der gefundenen Pakete) am Ende. Dies kann für Shellskripte nützlich sein, die die Ausgabe parsen.

-#, --only-names (toggle)

Wie --pure-packages, aber zusätzlich werden nur Kategorie und Name der gefundenen Pakete ausgegeben.

-0, --brief (toggle)

Ausgabe von höchstens einem Paket. Diese Option ist normalerweise schneller, wenn sie mit COUNT_ONLY_PRINTED=false kombiniert wird. In diesem Fall und zusammen mit Fuzzy-Suche wird nicht notwendigerweise der beste Treffer ausgegeben.

--brief2 (toggle)

Wie --brief, aber Ausgabe von bis zu zwei Paketen.

 

Spezielle Optionen für eix

-t, --test-non-matching

Vor anderer Ausgabe werden Einträge in /etc/portage/package.* ausgegeben, die kein passendes Pendant in der Paketdatenbank haben, oder die offensichtlich keine Bedeutung haben, weil sie leer sind (siehe TEST_FOR_EMPTY).

Diese Option listet ebenfalls alle installierten Pakete, deren Name nicht in der Datenbank zu finden ist.

Dies ist etwas prinzipiell anderes als -T (siehe unten). Das letztere überprüft nur für Pakete in der Datenbank, ob redundante Einträge in /etc/portage/package.* existieren bzw. ob die installierten Versionen vorhanden sind.

Am besten wird diese Option mit -T kombiniert, um /etc/portage/package.* aufzuräumen.

Oder sie kann mit -e kombiniert werden, um weitere Ausgaben zu verhindern.

Falls es einen Grund gibt, bestimmte Einträge/Pakete von diesem Test auszuschließen, können diese Einträge in eine Datei /etc/portage/package.*.nonexistent eingefügt werden. Hier steht * für eines der Worte accept_keywords (oder das obsolete keywords), mask, unmask, use, env, license, accept_restrict, cflags oder installed. Diese Dateien (und wie ihre Namen geändert werden können) wird später beschrieben.

-R, --remote

Benutzt den Wert von EIX_REMOTE1 als Namen für das Cachefile. Diese Option sollten Sie benutzen, wenn Sie das Ergebnis von <eix-remote> sehen wollen. Sie können diese Option als Standardeinstellung aktivieren, indem Sie REMOTE_DEFAULT=1 setzen.

-Z, --remote2

Benutzt den Wert von EIX_REMOTE2 als Namen für das Cachefile. Diese Option sollten Sie benutzen, wenn Sie das Ergebnis von <eix-remote> sehen wollen. Sie können diese Option als Standardeinstellung aktivieren, indem Sie REMOTE_DEFAULT=2 setzen.

--cache-file FILE

Benutzt FILE statt /var/cache/eix/portage.eix.

 

Optionen für AUSDRUCK

AUSDRUCK wird benutzt um die Suche zu spezifizieren.

Ein AUSDRUCK kann Boolesche Operatoren und Tests gemäß der folgenden Grammatik enthalten:

AUSDRUCK ::= [ --not | -! ] KLAMMER_ODER_TEST |
               AUSDRUCK [ --and| -a ] AUSDRUCK |
               AUSDRUCK [ --or | -o ] AUSDRUCK

KLAMMER_ODER_TEST ::= --open|-( AUSDRUCK --close|-) |
               TEST_MIT_OPTIONEN

TEST_MIT_OPTIONEN ::= [TEST_OPTIONEN] [SUCHMUSTER]

Bitte vergessen Sie nicht, dass !, (, ) in Shells normalerweise gequotet werden müssen, damit eix sie als Teil des Arguments erhält!

Falls ein AUSDRUCK mit - beginnen soll, stellen Sie einfach zwei weiter -- Zeichen davor: Auf diese Weise wird der AUSDRUCK nicht als Option interpretiert und zwei zusätzliche -- Zeichen werden ignoriert. Beispielsweise wird eix ---tool --or ---util diejenigen Pakete ausgeben die -tool or -util enthalten.

Die Bedeutung der logischen Operatoren sollte mit folgenden Ausnahmen offensichtlich sein:

1. Falls weder --and|-a noch --or|-o zwischen zwei AUSDRÜCKEN auftauchen, so wird eines von beiden implizit angenommen. Ob dies -a oder -o ist, hängt vom Wert der Konfigurationsvariable DEFAULT_IS_OR ab.

2. Die Operatoren -a und -o haben gleiche Bindungskraft und sind linksassoziativ. Insbesondere liefert X -o Y -a Z keinen Treffer, falls Z keinen Treffer liefert.

3. --not|-! negiert nur das Ergebnis des unmittelbar folgenden KLAMMER_ODER_TEST.

4. Falls SUCHMUSTER weggelassen wird, ist die Vorgabe ein leeres SUCHMUSTER. Beispielsweise wird eix mit den Standardeinstellungen ohne Argument alle Pakete ausgeben, da der leere String in jedem Namen enthalten ist. Andererseits sollte eix -e (normalerweise) nichts ausgeben, da kein Paketname (exakt) leer sein sollte.

5. Beachten Sie, dass die Syntax bedeutet, dass das SUCHMUSTER stets einen Ausdruck beendet. TEST_OPTIONEN nach SUCHMUSTER beginnt immer einen neuen Ausdruck (d.h. ein implizites --and oder --or wird eingefügt, je nach DEFAULT_IS_OR). Insbesondere hat eix -e foo eine andere Bedeutung als eix foo -e. Letzteres bedeutet das selbe wie eix foo --and -e or eix foo --or -e, je nach DEFAULT_IS_OR.

6. Beachten Sie, dass TEST_OPTIONEN mehrere Optionen enthalten kann. Diese werden alle zugleich angewendet, d.h. in gewissem Sinne werden diese Optionen logisch geklammert und mit and kombiniert (unabhängig von DEFAULT_IS_OR). Dies ist etwas zweideutig, da SUCHMUSTER weggelassen werden kann. Diese Zweideutigkeit wird so aufgelöst, dass aufeinanderfolgende TEST_OPTIONEN stets als ein Teil eines einzige TEST_MIT_OPTIONEN aufgefasst werden. Beispielsweise werden in eix -I -O -e foo alle Optionen als Teil eines einzigen AUSDRUCK interpretiert (nicht als vier AUSDRUCK-Argumente wie es etwas bei eix -I '' -O '' -e '' foo der Fall wäre). Andererseits wird das --not in eix -I --not -e nicht dazu führen, dass die darauffolgende TEST_OPTION -e als Teil eines neuen AUSDRUCKs verstanden wird. Andere Optionen als TEST_OPTIONEN oder logische Optionen (wie -!, -(, -), -a, -o) werden diesbezüglich ignoriert. Beispielsweise wird eix -I -c -e nur einen AUSDRUCK erzeugen, da -c weder eine TEST_OPTION noch eine logische Option ist und daher bei der Interpretation von AUSDRUCK keine Rolle spielt.

7. TEST_OPTIONEN kann Dinge wie den Match-Algorithmus oder die Operandenwahl festlegen. Alle diese Dinge beziehen sich only auf den aktuellen TEST_MIT_OPTIONEN; insbesondere sind sie nur für das nächste SUCHMUSTER aktiv.

Beachtne Sie ebenfalls, dass es neben dieser AUSDRUCK Syntax auch einen anderen Weg zur impliziten (allerdings langsamen) Paketwahl aufgrund anderer Kriterien gibt: Nämlich, indem man FORMATSTRING (siehe unten) mit entprechenden Konditionalen versieht, so dass es einen leeren String für ungewünschte Pakete ausgibt.

Es folgen die zulässigen TEST_OPTIONEN:

-I, --installed

Findet nur installierte Pakete. Benutzen Sie dies bitte nicht als Ersatz für eix-installed -a (oder qlist -ICv oder equery), da es nicht das selbe ist: Pakete, die installiert aber nicht mehr im Portage Tree (oder einem Overlay) sind, werden auf diese Weise nicht gelistet. Andererseits sollten Sie solche Pakete ohnehin besser nicht haben (es ist besser, diese Pakete in einen Overlay zu kopieren, falls sie irgendwann einmal reinstalliert werden müssen). Um solche Pakete zu finden, kann eix -te benutzt werden (oder eix -tI um beides auszugeben), aber dabei ist zu beachten, dass eix -t nicht die üblichen FORMAT rules auf diese Pakete anwendet. Dies sollte daher besser nicht in Skripten benutzt werden (falls Sie nicht genau wissen, was Sie da tun).

Falls Sie diese Option unbedingt als einen Ersatz für equery in Skripten benuzten wollen, dann werden Sie sie vermutlich mit einem der folgenden Optionen kombinieren wollen:

--format --only-names

--format '<installedversions:NAMEVERSION>' --pure-packages

--format '<installedversions:EQNAMEVERSION>' --pure-packages

--format '<installedversions:NAMESLOT>' --pure-packages

--format '<installedversions:NAMEASLOT>' --pure-packages

--format '<installedversions:DATESORT>' --pure-packages

-i, --multi-installed

Findet nur Pakete, die in mindestens zwei verschiedenen Versionen installiert sind. Normalerweise bedeutet dies, dass die Versionen geslotted sind (zumindest zu dem Zeitpunkt, als sie installiert wurden).

-d, --dup-packages

Findet nur doppelte Pakete, beispielsweise, falls sys-foo/bar im offiziellen Portagebaum und im lokalen Overlay existiert. Falls DUP_PACKAGES_ONLY_OVERLAYS gesetzt ist (siehe unten), müssen die Pakete in verschiedenen lokalen Overlays liegen.

-D, --dup-versions

Findet nur Pakete mit doppelten Versionen, beispielsweise, wenn sys-foo/bar-0.2.1 im offiziellen Portagebaum und im lokalen Overlay existiert. Falls DUP_VERSIONS_ONLY_OVERLAYS gesetzt ist (siehe unten), müssen die Ebuilds in verschiedenen lokalen Overlays liegen.

-1, --slotted

Findet nur Pakete mit einem nichttrivialen Slot, d.h. wenn Slot nichtleer ist und verschieden von "0".

-2, --slots

Findet nur Pakete mit mindesten zwei verschiedenen Slots. Anders als bei -1 wird hierbei ein Paket nicht gezeigt, falls nur ein Slot vorhanden ist, der z.B. den Slotnamen "4.3" trägt.

-u, --upgrade, --upgrade+, --upgrade-

Findet nur Pakete, die zumindest eine Version aus einem Slot installiert haben, die nicht die beste innerhalb des Slots ist. Dies bedeutet normalerweise, dass ein Upgrade/Downgrade des Pakets notwendig ist.

Dieser Test berücksichtigt auch UPGRADE_TO_HIGHEST_SLOT (siehe unten).

Für --upgrade+ oder --upgrade- verhält sich der Test, als wenn LOCAL_PORTAGE_CONFIG true bzw. false ist. Andernfalls wird diese Entscheidung von UPGRADE_LOCAL_MODE gefällt.

Falls Sie nur Pakete mit Downgrade-Empfehlung sehen wollen, können Sie die später beschriebenen FORMATSTRING-Features benutzen.

--stable, --testing, --non-masked, --system, --profile

Findet nur Pakete, die zumindest eine Version haben, die stabil (und nicht-maskiert), testing oder stabil (und nicht maskiert), nicht-maskiert, bzw. in @system oder @profile ist. Falls mehrere dieser Optionen in einem Test kombiniert werden, muss die selbe Version allen Kriterien genügen.

--stable+, --testing+, --non-masked+, --system+, --profile+

Wie eben, nur dass sich der Test so verhält, als wenn LOCAL_PORTAGE_CONFIG=true gesetzt wäre.

--stable-, --testing-, --non-masked-, --system-, --profile-

Wie eben, nur dass sich der Test so verhält, als wenn LOCAL_PORTAGE_CONFIG=false gesetzt wäre.

--installed-unstable, --installed-testing, --installed-masked

Findet nur Pakete, die zumindest eine nicht-stabile, testing, oder maskierte Version installiert haben (der Test verhält sich, als wenn LOCAL_PORTAGE_CONFIG=false gesetzt wäre). Falls mehrere dieser Optionen in einem Test kombiniert werden, muss die selbe Version alle Kriterien erfüllen.

--world

Findet nur Pakete aus @world. Dies ist analog zu "emerge @world", d.h. es enthält nicht nur die Pakete aus der world-Datei sondern auch aus world_set und das @system Set. Falls dies nicht alles enthalten sein soll, gibt es alternative Optionen.

--world-file

Findet nur Pakete aus der world-Datei oder aus dem @system Set.

--world-set

Findet nur Pakete aus world_set oder den @system Set. This only matches packages from world_set or from the @system set.

--selected

Findet nur @selected Pakete. Dies ist analog zu "emerge @selected", d.h. es enthält nicht nur Pakete im world-Datei sondern auch in world_sets (falls @system in world_set enthalten ist, ist das Verhalten natürlich identisch zu --world). Falls dies nicht alles enthalten sein soll, gibt es alternative Optionen.

--selected-file

Findet nur Pakete aus der world-Datei.

--selected-set

Findet nur Pakete aus world_set.

--binary

Findet nur Pakete mit einer Binärdatei (*.tbz2 oder *.xpak) in PKGDIR. Die Version des Binärfiles muss mit mindestens einer vorhandenen oder einer installierten Version übereinstimmen. (Falls keine Version vorhanden ist, kann das Paket ebenfalls nicht gefunden werden). Nur die reine Existenz einer entsprechenden Datei mit *.tbz2 oder *.xpak wird überprüft: Ob Portage die Datei tatsächlich benutzen kann, hängt auch von Meta-Daten innerhalb dieser Datei ab (wie etwa USE settings), was von eix nicht beachtet wird.

--nonvirtual

Findet nur Pakete mit mindestens einer Version aus dem Hauptbaum oder einem nicht-virtuellen Overlay.

--virtual

Findet nur Pakete mit mindestens einem nicht-virtuellen Overlay.

-O, --overlay

Findet nur Pakete mit mindestens einer Version in einem Overlay.

--in-overlay overlay

Findet nur Pakete mit mindestens einer Version in einem Overlay, der auf overlay passt.

Falls diese Option wiederholt wird, werden die zusätzlichen overlay-Argumente zu einer Liste zulässiger Overlays zusammengefasst.

overlay kann entweder ein Wildcard-Muster oder eine Zahl sein. Beachten Sie, dass sie mit der Standardeinstellung OVERLAYS_LIST=all-used-renumbered nicht die korrekten Overlaynummern sehen; für eine Liste der korrekten Overlaynummern können Sie beispielsweise den Aufruf

OVERLAYS_LIST=all eix --not

oder in Skripten besser

OVERLAYS_LIST=all PRINT_COUNT_ALWAYS=never eix -!

benutzen. Die speziellen Werte 0 oder $PORTDIR passen auf den Hauptbaum (der in diesem Zusammenhang als der 0-te Overlay betrachtet wird).

Falls overlay leer ist (or weggelassen wird, falls --in-overlay die letzte Option war) dann passen alle Overlays außer dem Hauptbaum (d.h. --in-overlay '' ist das selbe wie -O).

--only-in-overlay overlay

Findet nur Pakete, die nur Versionen haben, die in einem Overlay liegen, der auf overlay passt.

Falls diese Option wiederholt wird, werden die zusätzlichen overlay-Argumente zu einer Liste zulässiger Overlays zusammengefasst.

overlay kann entweder ein Wildcard-Muster oder eine Zahl sein, analog wie in --in-overlay. Insbesondere findet --only-in-overlay '' alle Pakete, die nicht im Hauptbaum sondern nur in Overlays liegen.

-J, --installed-overlay

Findet nur Pakete, die aus einem Overlay installiert wurden. Für vollkommen zuverlässige Ergebnisse sollte CHECK_INSTALLED_OVERLAYS=true gesetzt werden (was nicht die Standardeinstellung ist, weil es Tests massiv verlangsamt). Siehe CHECK_INSTALLED_OVERLAYS für Details.

--installed-from-overlay overlay

Dies ist analog zu --in-overlay mit dem Unterschied, dass nur Pakete gefunden werden, die zumindest eine Version aus overlay installiert haben. Beispielsweise wird --installed-from-overlay 0 nur die Pakete finden, bei denen zumindest eine Version aus dem regulären Portagebaum installiert ist. Wie für -J sollte CHECK_INSTALLED_OVERLAYS=true gesetzt werden, um vollständig zuverlässige Ergbnisse zu erhalten.

--installed-in-some-overlay

Findet nur Pakete, die zumindest eine Version installiert haben, die auch in einem Overlay zu finden ist.

--installed-in-overlay overlay

Dies ist analog zu --in-overlay mit dem Unterschied, dass nur Pakete gefunden werden, die zumindest eine installierte Version in overlay haben. Beispielsweise wird --installed-in-overlay 0 nur Pakete finden, die mindestens eine Version installiert haben, die es im regulären Portagebaum gibt.

--restrict-fetch

Findet nur Pakete, die zumindest eine Version mit RESTRICT=fetch haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-mirror

Findet nur Pakete, die zumindest eine Version mit RESTRICT=mirror haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-primaryuri

Findet nur Pakete, die zumindest eine Version mit RESTRICT=primaryuri haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-binchecks

Findet nur Pakete, die zumindest eine Version mit RESTRICT=binchecks haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-strip

Findet nur Pakete, die zumindest eine Version mit RESTRICT=strip haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-test

Findet nur Pakete, die zumindest eine Version mit RESTRICT=test haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-userpriv

Findet nur Pakete, die zumindest eine Version mit RESTRICT=userpriv haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-installsources

Findet nur Pakete, die zumindest eine Version mit RESTRICT=installsources haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-bindist

Findet nur Pakete, die zumindest eine Version mit RESTRICT=bindist haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--restrict-parallel

Findet nur Pakete, die zumindest eine Version mit RESTRICT=parallel haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--properties-interactive

Findet nur Pakete, die zumindest eine Version mit PROPERTIES=interactive haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--properties-live

Findet nur Pakete, die zumindest eine Version mit PROPERTIES=live haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--properties-virtual

Findet nur Pakete, die zumindest eine Version mit PROPERTIES=virtual haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

--properties-set

Findet nur Pakete, die zumindest eine Version mit PROPERTIES=set haben. Falls dies mit anderen PROPERTIES/RESTRICT tests kombiniert wird, muss die selbe Version alles gleichzeitig erfüllen.

-T, --test-obsolete

Findet nur obsolete Pakete.

Pakete sind obsolete, wenn sie redundante Einträge in /etc/portage/package.* haben (falls TEST_FOR_REDUNDANCY gesetzt ist), oder falls nicht alle installierten Versionen existieren (falls TEST_FOR_NONEXISTENT gesetzt ist).

Was als redundant gilt, wird durch die unten beschriebenen <REDUNDANT_IF>-Variablen festgelegt, und was als nicht-existent betrachtet wird, wird durch die NONEXISTENT_IF-Variablen festgelegt. Der Test für Versionen von obsoleten Overlays funktioniert nur dann zuverlässig, wenn CHECK_INSTALLED_OVERLAYS=true gesetzt ist (was nicht die Standardeinstellung ist, weil es Tests dramatisch verlangsamt). Siehe CHECK_INSTALLED_OVERLAYS für Details.

Beachte, dass diese Option nur Pakete in der Datenbank test. Insbesondere werden keine Einträge für beispielsweise umbenannte oder aus dem Portagebaum gelöschte Pakete mit dieser Option gefunden werden. Letzteres wird mit der Option -t bedient.

Daher wird diese Option am Besten mit -t kombiniert, wenn auch andere Arten obsoleter Einträge gefunden werden sollen.

Falls es einen Grund gibt, bestimmte Pakete von diesem Test auszuschließen, so können diese Einträge in die Datei (oder Verzeichnis) /etc/portage/package.nowarn geschrieben werden. Diese Datei (und wie alternative/zusätzliche Dateien angegeben werden können) wird später beschrieben.

-|, --pipe

(Beachten Sie, dass die Shell normalerweise kein |-Zeichen übergibt, wenn es nicht gequotet ist).

Findet nur Pakete/Masken aus Standard-Input; normalerweise wird dies in einer Pipe benutzt, etwa als Ausgabe von emerge -pv (oder genlop -p). Tatsächlich werden im Input alle Worte (durch Leerzeichen oder Zeilenende separiert) beachtet, die das Zeichen / enthalten.

Jedes solche Wort wird als Maske betrachtet (in der Form des ersten Eintrags der /etc/portage/package.*-Dateien), aber eine Heuristik erlaubt, dass Versionen auch ohne ein explizites führendes =-Zeichen angegeben werden können. (Dies kann zu Mehrdeutigkeiten führen; benutzen Sie --pipe-mask, wenn Sie ein zuverlässiges Ergebnis benötigen).

Alle verfügbaren Pakete/Versionen, die auf eine Maske der Standardeingabe passen, werden in der Ausgabe als markiert behandelt. Details zu Letzterem stehen in der Beschreibung der marked und markedversions:* Formatstrings.

Auch wenn --pipe mehr als einmal auftaucht, wird die Standard-Eingabe natürlich nur einmalig gelesen, aber wiederholt für jedes Auftauchen interpretiert (d.h. falls der erste --pipe Ausdruck passt, werden auch alle anderen passen).

Falls der Standard-Input nur zum Markieren aber nicht zur Auswahl benutzt werden soll, kann etwa folgender Ausdruck benutzt werden:

eix irgendwas -a "-(" --pipe -o "-)"

Falls die Option --pipe-name oder --pipe-version später in der Argumentliste vorkommt, verhält sich -pipe wie --pipe-name bzw. --pipe-version.

--pipe-name

Dies ist analog zu --pipe mit dem Unterschied, dass nur Masken in der Eingabe erlaubt sind, d.h. bei der Angabe von Paketversionen ist ein führendes =-Zeichen nicht optional. Dies verhindert Mehrdeutigkeiten, wenn ein Teil des Namens wie eine Versionsnummer aussieht. Benutzen Sie diese Option anstelle von --pipe für ein zuverlässiges Ergebnis!

 

Operandenwahl

Die nachfolgenden Optionen legen die Felder fest, auf die SUCHMUSTER passen soll. Mehrere Felder können in einem Ausdruck festgelegt werden (der Ausdruck passt, falls das Suchmuster auf mindestens eines der spezifierten Felder passt). Falls keine diese Optionen angegeben wird, wird die Vorgabeeinstellung anhand einer Heuristik gewählt, die von der Form von SUCHMUSTER abhängt. In den meisten Fällen wird das Vorgabefeld --name sein, aber wenn das SUCHMUSTER "speziell" aussieht, etwa "cat/n" oder "@set", so wird das Vorgabefeld auf --category-name, --set, --description, --homepage oder --license geändert. Details der Heuristik werden in der später erklärten DEFAULT_MATCH_FIELD-Konfigurationsvariable festgelegt. Je nach Wert dieser Variablen kann es auch passieren, dass eine der folgenden Optionen explizit für jede Suche angegeben werden muss.

-y, --any

Jedes Feld wird durchsucht. Dies ist gleichbedeutend damit, gleichzeitig alle Optionen --name, --description, --category, ... anzugeben. Man wird dies immer dann wählen, wenn man sicher sein möchte, keine Treffer zu übersehen. Man sollte allerdings damit rechnen, dass die Trefferliste viel länger als erwartet sein wird. (Wer neugierig ist, kann mit den Optionen -vl and Weiterleitung nach grep den oft unerwarteten Grund herausfinden, weshalb ein Treffer bei -y auftaucht). Um zumindest den Abhängigkeitsstring von der Suche auszunehmen, empfiehlt sich manchmal die Kombination mit DEP=false, z.B.

DEP=false eix --any SIP

-s, --name

z.B. "eix"

-S, --description

z.B. "Small utility for searching .."

-C, --category

z.B. "app-portage"

-A, --category-name

z.B. "app-portage/eix"

-H, --homepage

z.B. "https://github.com/vaeth/eix/"

-L, --license

z.B. "GPL-2"

--available-deps, --available-depend, --available-rdepend, --available-pdepend, --available-bdepend

Dieser Test kann nur dann etwas finden, wenn DEP=true benutzt wird (und DEP=true bei der Erzeugung des Cachedatei benutzt wurde). Er tested gegen DEPEND, RDEPEND, PDEPEND bzw. BDEPEND (oder mit --deps gegen irgendeines davon) für irgendeine verfügbare Version des Pakets. --deps ist das gleiche wie --depend --rdepend --pdepend --bdepend. Beachten Sie, dass gegen den String ohne irgendwelche Interpretatino oder Modifikation getestet wird; nur Wort-Trenner werden einzelne Leerzeichen. Insbesondere kann der String, gegen den getestet wird, so aussehen:

app-admin/fam nls? ( sys-devel/gettext ) =dev-libs/apr-1* !!dev-db/libpq

Daher ist der Test tatsächlich nicht nur gegen abhängige Pakete, sondern auch gegen Blocker und/oder Konditionale und gegen verschiedene Möglichkeiten, Versionen zu spezifizieren.

--installed-deps, --installed-depend, --installed-rdepend, --installed-pdepend, --installed-bdepend

Diese Optionen sind ähnlich zur entsprechenden --available-* Option, aber mit dem Unterschied, dass der entsprechende Abhängigkeitsstring aus den installierten Versionen des Pakets genommen wird. Im Gegensatz zu --available-* wird dieser Test nicht von DEP beeinflusst. Diese Option wird üblicherweise mit --deps-installed kombiniert um sicherzustellen, dass tatsächlich der Inhalt der installierten Version gelesen wird.

Man beachte, dass Abhängigkeiten installierter Versionen i.d.R. viel einfacher sind und z.B. keine Konditionale enthalten.

--deps, --depend, --rdepend, --pdepend, --bdepend

Dies sind Abkürzungen für die gleichzeitige Angabe der entsprechenden --avilable-* und --installed-* Optionen.

--set

Name eine lokalen Paket-Sets oder Version in der Datenbank (d.h. entsprechend einer Datei aus /etc/portage/sets, /etc/portage/sets.eix, oder eines anderen Verzeichnisses ausEIX_LOCAL_SETS_ADD; siehe die Kommentare zu EIX_LOCAL_SETS). Die "profile", "system" und "world" sets sind hier bewusst ausgenommen, da diese mit --profile[+-], --system[+-], --world, --world-all oder --world-sets getestet werden sollten.

--src-uri

SRC_URI einer Version in der Datenbank.

--eapi

EAPI einer Version in der Datenbank, z.B. "6"

--installed-eapi

EAPI einer installierten Version

--slot

Slotname einer Version in der Datenbank, z.B. "kde-4"

--fullslot

Slotname einer Version in der Datenbank ggf. mit Subslot, z.B. "3/1.4"

--installed-slot

Slotname einer installierten Version. Beachten Sie, dass ohne die Option --care (oder CAREMODE=true) der Slotname ev. nur vermutet wird.

--installed-fullslot

Slotname einer installierten Version ggf. mit Subslot. Beachten Sie, dass ohne die Option --care (oder CAREMODE=true) der Slotname ev. nur vermutet wird.

-U, --use

Ein Useflag, das im IUSE mindestens eines Ebuilds von einer Version des Pakets festgelegt wird. Normalerweise wird diese Option mit -e kombiniert.

--installed-with-use

Ein Useflag, das während der Installation eines Pakets aktiv ist. Natürlich kann dieser Test nur dann erfolgreich sein, wenn das Paket installiert ist. Es gelten die selben Einschränkungen wir für -I, d.h. nur diejenigen Pakete werden gefunden, die es noch in der Datenbank gibt.

--installed-without-use

Ein Useflag, das während der Installation eines Pakets inaktiv ist. Natürlich kann dieser Test nur dann erfolgreich sein, wenn das Paket installiert ist. Es gelten die selben Einschränkungen wir für -I, d.h. nur diejenigen Pakete werden gefunden, die es noch in der Datenbank gibt.

 

Match-Algorithmus

Die folgenden Optionen legen den Algorithmus fest, nach dem das Operandenfeld gegen das SUCHMUSTER getestet werden soll. Nur ein Algorithmus kann pro AUSDRUCK gewählt werden. Falls keine dieser Optionen benutzt wird, wird die Vorgabe anhand einer Heuristik ausgewählt, die von der Gestelt des Suchmusters und vom ausgewählten Operandenfeld abhängt. In den meisten Fällen wird diese Vorgabe --regex sein, außer wenn das Suchmuster aussieht wie "typischerweise" ein glob-Muster or ein Teilstring (in diesem Fall wird der entsprechende Algorithmus die Vorgabe), oder falls das ausgewählte Operandenfeld sich nur auf USE-flags, sets, EAPI oder SLOT bezieht, so dass die meisten Benutzer vermutlich erwarten, dass auch tatsächlich gegen den gesamten String getestet werden soll. Details der Heuristik werden in der später erklärten DEFAULT_MATCH_ALGORITHM-Konfigurationsvariable festgelegt. Je nach Wert dieser Variablen kann es auch passieren, dass eine der folgenden Optionen explizit für jede Suche angegeben werden muss.

-e, --exact

Das Suchmuster ist ein exakter (ganzer) String. Beispielsweise zeigt "eix -e gcc" nur Pakete des namens "gcc".

-b, --begin

Das Suchmuster ist ein Stringanfang. Beispielsweise zeigt "eix -b gcc" die Pakete mit dem Namen "gcc", aber beispielsweise auch "gcc-config".

--end

Das Suchmuster ist ein Stringende.

-z, --substring

Das Suchmuster taucht irgendwo im String auf.

-f [N], --fuzzy [N]

Fuzzy-Suche mit dem maximalen Levenshtein-Abstand N (default ) für den ganzen String. Diese Option reduziert die Suchgeschwindigkeit.

-p, --pattern

Das Suchmuster ist ein Wildcard-pattern (gegen desn gesamten String. Siehe fnmatch(3) und/oder glob(7) für weitere Details. Vorsicht bei der Übergabe des Suchmusters in einer Shell (Quoting!).

-r, --regex

Das Suchmuster ist ein regulärer Ausdruck. Nur ein Teilstring muss passen (außer wenn ^ oder $ benutzt werden). Das leere Suchmuster passt auf alles. Weitere Informationen finden sich in regex(7). Vorsicht bei der Übergabe des Suchmusters in einer Shell (Quoting!).

 

Layouts festlegen (siehe FORMATSTRING weiter unten)

--format FORMATSTRING

Definiert den FORMATSTRING. Seit eix-0.29.6 überschreibt diese Option alle anderen Möglichkeiten zur Wahl des Formatstrings wie etwa das Setzen von DEFAULT_FORMAT oder FORMAT. Wird diese Option hingegen nicht benutzt, sondern statt dessen eine der Variablen FORMAT, FORMAT_VERBOSE, oder FORMAT_COMPACT gesetzt, so hängt die Wahl des Formats vom wert von DEFAULT_FORMAT ab und kann zusätzlich noch durch die Optionen --verbose, --compact bzw. --normal beeinflusst werden.

 

Spezielle Optionen für eix-update

-H, --nostatus

Kein Update der Statuszeile.

--force-status

Update der Statuszeile, selbst wenn die Ausgabe kein Terminal ist oder falls TERM nicht mit einem Wort aus TERM_STATUSLINE beginnt.

-o Ausgabedatei, --output Ausgabedatei

Mit dieser Option schreibt eix-update die eix-Datenbank nach Ausgabedatei statt /var/cache/eix/portage.eix. Mit dieser Option wird die gesetzte umask berücksichtigt. Andernfalls wird die umask zwangsläufig auf 002 zur Erzeugung der Datei gesetzt.

-a Overlay, --add-overlay Overlay

Dies ist ähnlich wie Overlay to PORTDIR_OVERLAY zu /etc/portage/make.conf oder zu ADD_OVERLAY hinzuzufügen, hat aber den Vorteil, dass Letztere nicht modifiziert werden müssen, und dass es problemlos möglich ist, Leerzeichen in Overlay zu benutzen. Overlays mit dieser Option kommen nach Overlays aus KEEP_VIRTUALS. Falls Overlay bereits in der Liste der Overlays enthalten ist, so hat diese Option keine Auswirkingen. Es ist ausdrücklich zulässig, diese Option wiederholt zu benutzen, um mehrere Overlays hinzuzufügen.

-x Overlay, --exclude-overlay Overlay

Dies ist ähnlich wie Overlay to EXCLUSE_OVERLAY hinzuzufügen, hat aber den Vorteil, dass Letzteres nicht modifiziert werden muss, und dass es problemlos möglich ist, Leerzeichen in Overlay zu benutzen. Overlay wird als Maske aufgefasst. Alle passenden Overlays (auch diejenigen, die später mit --add-overlay hinzugefügt wurden), werden aus der Liste der Overlays ausgeschlossen. Das PORTDIR-Verzeichnis wird als ein weitere Overlay betrachtet, der ausgeschlossen werden kann (in diesem Fall wird der erste Overlay der Liste als PORTDIR gespeichert). Es ist ausdrücklich zulässig, diese Option wiederholt zu benutzen, um mehrere Overlays auszuschließen.

-m Overlay Methode, --override-method Overlay Methode

Ändert die Cachemethode von Overlay (der PORTDIR-Verzeichnis ist ein erlaubter Overlay) auf Methode. Overlay wird als Maske betrachtet, d.h. es darf Wildcards enthalten. Falls Overlay auf nichts in der Liste der Overlays passt, hat diese Option keine Auswirkungen. Diese Option ist ähnlich wie das Hinzufügen des Eintrags "Overlay Methode" am Ende der OVERRIDE_CACHE_METHOD-Variablen. Es ist ausdrücklich zulässig, die Option wiederholt zu benutzen, um Cachemethoden für verschiedene Overlays zu überschrieben. Die zuletzt passende Überschreibung gewinnt. Insbesondere kann man mit dieser Option den Inhalt von OVERRIDE_CACHE_METHOD überschreiben.

-r Overlaypfad Overlaylabel, --repo-name Overlaypfad Overlaylabel

Der Overlay Overlay-path erhält das Lebel Overlaylabel, unabhängig von anderen Settings. Dies kann mit REPO_NAMES überschrieben werden. Im Gegensatz zu REPO_NAMES ist Overlaypfad kein Muster sondern ein genauer Pfad.

-v --verbose

Gibt die effektiv benutzte Cachemethode für jedes Ebuild aus. Dies erzeugt eine Menge an Ausgaben und ist hauptsächlich zum Debuggen nützlich, etwa wenn unklar ist, weshalb eix-update schneller/langsamer ist als erwartet.

 

AUSGABE

 

Slots

Anders als in der üblichen Ausgabe von Versionen in emerge kann <eix> auch Slotnamen ausgeben, wenn sie nichttrivial (leer oder "0") sind. Ob dies geschieht, wird u.a. durch FORMATSTRING festgelegt.

Falls Slots ausgegeben werden, wird der Slotname entweder mit einem Doppelpunkt von der Versionsnummer abgetrennt, oder der Slotname wird in Klammern geschrieben. Der bevorzugte Modus wird in der Variable COLON_SLOTS festgelegt.

Falls PROPERTIES oder RESTRICT im Ebuild gesetzt sind, wird dies bei Standardeinstellung im Versionsstring angezeigt; Details können durch Setzen von Konfigurationsvariablen beeinflusst werden.

Einige Beispiele:

4.1.1:4.1 oder 4.1.1(4.1)

Dies ist Version 4.1.1, die in den Slot "4.1" installiert wird.

3.14p:GNAT-3.14p oder 3.14p(GNAT-3.14p)

Dies ist Version 3.14p, die in den Slot "GNAT-3.14p" installiert wird.

2.0.0_rc1-r6

Dies ist Version 2.0.0_rc1-r6, und der SLOT ist leer oder "0".

1.0*ilvs^fmpbstuidP{tbz2,pak:2}

Dies ist Version 1.0, und gesetzt sind PROPERTIES="interactive live virtual set" sowie RESTRICT="fetch mirror primaryuri binchecks strip test userpriv installsources bindist parallel". Darüberhinaus existiert eine *.tbz2 und zwei *.xpak-Dateien (Binärpakete ohne bzw. mit FEATURES==binpkg-multi-instance) für diese Version in PKGDIR.

5.0-r3(5.0R3)^f oder 5.0-r3:5.0R3^f

Dies ist Version 5.0-r3, die in Slot 5.0R3 installiert wird, und die RESTRICT=fetch hat.

 

Maskierung

Wer Gentoo für mehr als eine Woche benutzt hat, wird vermutlich sofort das Format für die Maskierung von Versionen verstehen. Nichtsdestotrotz wird es hier anhand einiger Beispiele erklärt. Es wird natürlich nur die Ausgabe bei Standardeinstellungen beschrieben; Details können durch Konfigurationsvariablen beeinflusst werden.

[P]2.95.3-r8

Eine Maske für das Paket wurde in der packages-Datei des Profiles gefunden, aber diese Version passt nicht. Portage nennt dies "masked by profile".

[M]4.0.0_alpha20050213

Die Version passt auf einen Eintrag aus /etc/portage/package.mask, $PORTDIR/profiles/package.mask oder einer package.mask des Profiles. Portage nennt dies "masked by package.mask".

[m]4.1.4

Die Version passt zu einer lokalen Maske (von /etc/portage/package.mask), aber sie ist weder "masked by profile" noch in $PORTDIR/profiles/package.mask maskiert.

{P}2.95.3-r8

Die Version war ursprünglich "masked by profile", aber dies wurde lokal durch /etc/portage/profile/packages geändert.

{M}4.0.0_alpha20050213

Die Version war ursprünglich in $PORTDIR/profiles/package.mask, aber dies wurde lokal durch /etc/portage/package.unmask geändert.

*3.3.3

Die Version ist "masked by missing keyword", aber stabil für eine fremde Architektur.

~*3.3.3

Die Version ist "masked by missing keyword", auf keiner Architektur stabil, aber auf einer fremden Architektur instabil.

**3.3.3

Die Version ist "masked by missing keyword" für alle Architekturen.

(**)3.4.3-r2

Die Version hatte ursprünglich kein Keyword, aber dies wurde lokal geändert (in /etc/portage/package.{accept_,}keywords oder durch ACCEPT_KEYWORDS).

-0.8.14

Maskiert durch -ARCH.

~3.3.5.20050130

Die Version ist "masked by ~keyword".

(~)3.3.5.20050130

Die Verstion war ursprünglich "masked by ~keyword", aber dies wurde lokal geändert (in /etc/portage/package.{accept_,}keywords oder durch ACCEPT_KEYWORDS).

[M]~1.0.9626

Diese Version ist sowohl "masked by package.mask" als auch "masked by ~keyword".

[m](~)4.1.4-r1

Die Version was ursprünglich nur "masked by ~keyword", aber dies wurde lokale geändert (in /etc/portage/package.{accept_,}keywords oder durch ACCEPT_KEYWORDS). Darüberhinaus wurde die Version lokal maskiert (in /etc/portage/package.mask).

3.3.1

Dies schließlich ist eine stabile Version (die auch ohne lokale Settings stabil wäre).

 

eix-diff

Die Ausgabe von eix-diff wird vollständig durch Konfigurations-Variablen kontrolliert (DIFF_FORMAT_NEW, DIFF_FORMAT_DELETE, DIFF_FORMAT_CHANGED und eine Menge Variablen die - zumindest in der Standardeinstellung - durch diese über verzögerte Ersetzung benutzt werden, s. unten). Die folgende Erklärung anhand von Beispielen kann daher nur das Verhalten der Standardeinstellung der aktuellen eix-Versin beschreiben. Obwohl dieses Standardeinstellung lange Zeit unverändert blieb, wird keine Stabilität der Standardeinstellungen für zukünftige eix-Versionen garantiert.

[N] >> foo/bar (~1.0): description of foo/bar

Das Paket foo/bar ist neu im Baum.

[*N] >> foo/bar (1.0): description of foo/bar

Das Paket foo/bar ist neu im Baum. Darüberhinaus hat as eine Version (1.0), die ohne Demaskieren/Keywording installiert werden könnte.

<< foo/bar ({M}1.0): description of foo/bar

foo/bar wurde aus dem Baum entfernt; die vorherhige Version 1.0 war maskiert, aber sie ist derzeit nicht mehr maskiert. (wahrscheinlich, weil der Entwickler den entsprechenden Eintrag der package.mask-Datei zusammen mit der Löschung des Pakets entfernt hatte).

[*>] == foo/bar (1.0): description of foo/bar

Der Status des Pakets foo/bar im Baum hat sich geändert (für die lokalen Settings): es hat eine Version (1.0) erhalten, die ohne lokales Demaskieren/Keywording installiert werden könnte, währen der im vorherigen Baum foo/bar keine solche Version existierte. Darüberhinaus bedeutet das > dass ein Slot eine höhere Version erhielt. In diesem Fall ist tatsächlich die selbe Änderung für die beiden Symbole > und * verantwortlich.

[><] == foo/bar (1.1(1) 2.0(2) -> 1.0(1) 2.1(2)): description

Der Status des Pakets foo/bar im Baum hat sich geändert (für die lokalen Settings): Die Symbole an der linken Seite bedeuten, dass ein Slot eine höhere Version erhielt (die ohne Äderung von Maske/Keywords installiert werden könnte), ein anderer Slot verlor eine solche "beste" Version. Durch Betrachten der Versionsstrings wird klar, dass Slot 2 eine neue Version erhielt (die vorherige stabile dieses Slots war 2.0m die neue ist 2.1), und das die vorherige höchste stabile Version 1.1 des Slots 1 entfernt oder maskiert wurde (die aktuell stabile Version dieses Slots ist jetzt 1.0).

[U?] == foo/bar (1.1(1)@01.01.2009; 1.1(1) -> 2.0(2)): description

Der Status des Pakets foo/bar im Baum hat sich geändert (für die lokalen Settings): Die Symbole an der linken Seite bedeuten, dass für einen installierten Slot ein Upgrade möglich ist (ohne Veränderung von Maske/Keywords), und das ein anderer installierter Slot entfernt/maskiert wurde. Durch Betrachten der Versionsstrings wird klar, dass die installierte Version 1.1 des Slots 1 entfernt oder maskiert wurde, und dass es keine andere installierte Version des Slots 1 gibt. Eine stabile Version 2.0 erschien neu im Slot 2 (d.h. Slot 2 existiere vorher nicht oder hatte keine stabile Version).

Da keine Version des Slots 2 installiert war, kann eix in dieser Situation nicht entscheiden, ob das Symbol "U" wirklich angemessen ist: Da eix keine Abhängigkeiten berücksichtigt, weiß es nicht, ob der neue Slot beispielsweise von der world-Datei benutzt würde, oder ob es nur eine Abhängigkeit für den alten Slot gibt. Daher wird das Symbol "U" in dieser Situation nur angezeigt, falls UPGRADE_TO_HIGHEST_SLOT=true or falls das Paket in /etc/portage/package.slot_upgrade_allow gelistet ist.

Tatsächlich wäre der output [U?><] == foo/bar ... konsistenter, weil zusätzlich ein Slot eine höhere stabile Version erhielt und die höchste stabile Version eines anderen Slots entfernt wurde. Aber weil dies tyopischerweise von "U" bzw. "?" impliziert ist, war es bei den Standardeinstellungen eine Design-Entscheidung, dass bei der Ausgabe von U oder ? die Ausgabe der Symbole < bzw. > unterdrückt wird. Natürlich ist es möglich, einen anderen DIFF_FORMAT_HEADER_CHANGED-String zu definieren, der einer anderen Politik folgt.

 

FORMATSTRING

Ein Formatstring kann konditionelle Blocks, Paketeigenschaften, Farben, und normale Strings enthalten. Normale Strings werden wie erwartet ausgegeben (wobei spezielle Escape-Sequenzen berücksichtigt werden, s. unten); für die Berechnung von Größen wie z.B. Tabs wird UTF8-Kodierung unterstellt.  

konditionelle Blocks

Bedingungen sind sehr einfach: Eine Eigenschaft wird expandiert, und der erhaltene String wird gegen einen anderen String getestet. Wenn sie übereinstimmen, ist die Bedingung wahr, und der Block wird ausgeführt. Bedingungen können negiert werden, so dass der else-Teil ausgeführt wird, falls die Bedingung wahr ist, und der if-Teil, falls die Bedingung falsch ist. Der else-Teil kann auch weggelassen werden.

{[!]EIGENSCHAFT[=RHS]}TCODE{}

Führt TCODE aus, falls der String aus der Expansion von EIGENSCHAFT gleich RHS ist. Das ! würde das Verhalten negieren.

{[!]EIGENSCHAFT[=RHS]}TCODE{else}FCODE{}

Führt TCODE aus, falls der string aus der Expansion von EIGENSCHAFT gleich RHS ist. Andernfalls wird FCODE ausgeführt.

RHS ist entweder eine Eigenschaft (falls in <> eingeschlossen), eine variable (falls ein $ vorgestellt ist), oder ein String (in allen anderen Fällen, oder falls in Anführungszeichen).

EIGENSCHAFT kann entweder eine der unten spezifierten Paketeigenschaften sein oder ein Variablenzugriff. Ein Variablenzugriff hat die Gestalt $VARIABLE. VARIABLE muss nicht initialisiert werden; der Vorgabewert ist der Leerstring.

Um VARIABLE zur Laufzeit zu ändern, dient diese Syntax:

{[!]*VARIABLE[=RHS]}

Dies sehr die Laufzeit-Variable VARIABLE auf RHS. Mit ! ist das Ergebnis 1 oder leer, je nachdem ob RHS leer ist. Falls der zweite Teil (einschließlich des =-Zeichens) weggelassen wird, gibt es eine spezielle Bedeutung: {*VARIABLE} setzt die VARIABLE auf 1, {!*VARIABLE} setzt die VARIABLE auf den Leerstring.

 

Paketeigenschaften

Namen, die sich auf spezielle Eigenschaften des Pakets beziehen, das gerade ausgegeben wird. Falls der Name benutzt werden soll, um eine Paketeigenschaft auszugeben, muss der name in spitzen Klammern geschrieben werden (d.h. "<name>").

name, category, homepage, licenses

Name, Kategorie, Homepage and Lizenz des aktuellen Pakets.

availableversions:VARIABLE, availableversions:VARIABLE:VARSLOTS

Für jede Version wird der Inhalt der Konfigurations/Environment-Variablen VARIABLE ausgegeben, wobei diese als Formatstring interpretiert wird. In der zweiten Form, und falls mindestens ein Slot des Pakets nichttrivial ist, wird VARSLOTS statt VARIABLE benutzt, und die versionen werden entsprechend der Slots sortiert.

Um Missverständnisse zu vermeiden: Es ist nicht möglich, das gewünschte Format direkt nach dem Doppelpunkt anzugeben. Statt dessen muss das gewünschte Format in einer neuen Variable gespeichert werden, und VARIABLE und VARSLOTS sind nur die Namen dieser Variablen.

Nützliche Beispiele für VARIABLE sind NAMEVERSION, EQNAMEVERSION, EQNAMEVERSION, ANAMESLOT, ANAMEASLOT, NAMESLOT, NAMEASLOT oder DATESORT. Hierbei sind ANAMESLOT und ANAMEASLOT dazu gedacht, in der zweiten Form benutzt zu werden, d.h. in availableversions:ANAMESLOT:ANAMESLOT oder availableversions:ANAMEASLOT:ANAMEASLOT (Mnemonic: ASLOT print slot always). NAMESLOT, NAMEASLOT und DATESORT ist nur für installierte Versionen sinnvoll. Siehe eix --dump für die genaue Definition der Variablen.

markedversions:VARIABLE, markedversions:VARIABLE:VARSLOTS

Dies ist analog zu availableversions mit dem Unterschied, dass nur markierte (verfügbare) Versionen ausgegeben werden.

bestversion:VARIABLE, bestversion*:VARIABLE, bestslotversions:VARIABLE, bestslotversions*:VARIABLE, bestslotupgradeversions:VARIABLE, bestslotupgradeversions*:VARIABLE

Dies ist analog zu availableversions mit dem Unterschied, dass nur die beste Version bzw. die beste Version eines jeden Slots ausgegeben wird. Für die Varianten mit * werden auch unstabile Versionen akzeptiert. Für die Varianten mit upgrade werden nur diejenigen Versionen selektiert, die voraussichtlich nach dem Upgrade erscheinen.

installedversions:VARIABLE

Dies ist analog zu availableversions mit dem Unterschied, dass nur installierte Versionen ausgegeben werden.

first, last, slotfirst, slotlast, oneslot

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Diese Flags können benutzt werden um zu testen, ob gerade die erste oder letzte Version eine Pakets ausgegeben wird (etwa um Zusatztext in diesen Fällen auszugeben). Analog, wenn die Ausgabe nach Slot sortiert wird, kann damit getestet werden, ob die aktuelle Version die erste oder letzte des aktuellen Slots ist, oder ob es gar überhaupt nur einen Slot gibt. Alle diese Eigenschaften sind leer, wenn die Bedingung nicht erfüllt ist, sonst 1. Um die Wiederbenutzung von Code zu erleichtern gilt: Wenn die Durckausgabe nicht Slot-sortiert ist, dann sind slotfirst/slotlast äquivalent zu first/last, und oneslot ist 1.

srcuri,havesrcuri

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Sie gibt die SRC_URI einer verfügbaren Version aus bzw. 1, wenn SRC_URI nicht leer ist.

eapi

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Sie gibt die EAPI einer verfügbaren oder installierten Version aus.

slot, isslot, fullslot, isfullslot, subslot, issubslot

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Es wird der Slot/Subslot/beides der aktuellen Version ausgegeben. isslot, isfullslot und issubslot testen nur of Slot, voller Slot bzw. Subslot trivial sind und geben in diesem Fall 1 aus (sonst nichts).

overlayver, overlaynum, overlayvername, virtual

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Es wird der Overlay der aktuellen Version ausgegeben. overlayver ist der farbige Index des Overlays und leer, falls das gesamte Paket von nur einem Overlay stammt; in so einem Fall sollte overlaykey zur Ausgabe des Overlays benutzt werden. Im Gegensatz dazu enthält overlaynum stets die Nummer des Overlays (ohne Farben) oder ist leer, falls die Version keinem Overlay entstammt. overlayplainname ist das Label (Name) (oder Pfad für unbekanntes oder leeres Label) des Overlays; overlayplainame* betrachtet dabei auch den Hauptbaum als Overlay. overlayvername und overlayvername* sind analogous, kehren aber mit einem leeren String zurück, falls das Paket vom selben Overlay stammt. virtual ist genau dann nichtleer, wenn die Version aus einem virtuellen Overlay kommt.

versionkeywords, versionkeywords*, versionekeywords

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Die vollen Keywords der aktuellen Version werden ausgegeben. Falls die Daten durch das Profile modifiziert wurden, werden die modifizierten Daten mit versionkeywords* ausgegeben. Die spezielle Form versionekeywords gibt letzteres aus, falls es sich von versionkeywords unterscheidet; andernfalls ist es leer.

isbestupgrade, isbestupgrade*, isbestupgradeslot, isbestupgradeslot*

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Dies expandiert zu 1, falls die aktuelle Version die beste bzw. beste des aktuellen Slots zum Upgraden ist. Für die Varianten mit * werden auch instabile Versionen berücksichtigt.

installedversion, markedversion

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Expandiert zu 1 oder dem Leerstring, je nachdem ob die aktuelle verfügbare Version installiert bzw. markiert ist. Für markedversions schlägt dieser Test im Zusammenhang mit <installedversions:...> immer fehl.

ishardmasked, washardmasked, isprofilemasked, wasprofilemasked, ismasked, wasmasked, isstable, wasstable, isunstable, wasunstable, isalienstable, wasalienstable, isalienunstable, wasalienunstable, ismissingkeywordwasminusasterisk

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Expandiert zu 1 oder dem Leerstring, je nachdem ob die aktuelle Version (gemäß der lokelen bzw. Standard-Konfiguration) die entsprechend Stabilitätseigenschaft hat.

isbinary

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Dies ist 1 oder leer, je nachdem ob eine entsprechende Datei mit *.tbz2 oder *.xpak für die Version existiert.

istbz

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Dies ist 1 oder leer, je nachdem ob eine entsprechende Datei mit *.tbz2 für die Version existiert.

ispak

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Dies ist 1 oder leer, je nachdem ob eine entsprechende Datei mit *.xpak für die Version existiert.

ismultipak

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Dies ist 1 oder leer, je nachdem ob mindestens zwei Dateien mit *.xpak für die Version existieren.

pakcount

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Es enthält die Anzahl der Dateien mit *.xpak für die Version. Falls keine existiert, ist es leer.

restrict, restrictfetch, restrictmirror, restrictprimaryuri, restrictbincheck, restrictstrip, restricttest, restrictuserpriv, restrictinstalledsources, restrictbindist, restrictparallel

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Dies ist 1 oder leer, je nachdem ob eine entsprechendes RESTRICT-Attribut für die Version gesetzt ist.

properties, propertiesinteractive, propertieslive, propertiesvirtual, propertiesset

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Dies ist 1 oder leer, je nachdem ob eine entsprechendes PROPERTIES-Attribut für die Version gesetzt ist.

depend, rdepend, pdepend, bdepend, depend*, rdepend*, pdepend*, bdepend*

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Es expandiert zum DEPEND, RDEPEND, PDEPEND bzw. BDEPEND einer vorhandenen Version (der String wird nach Möglichkeit abgekürzt, falls die Variante mit * benutzt wird). Die Expansion ist leer, falls DEP=true nicht gesetzt ist (oder bei der Erzeugung der Datenbank nicht gesetzt war).

havedepend, haverdepend, havepdepend, havebdepend, havedeps

Wie oben mit dem Unterschied, dass nur 1 ausgegeben wird, wenn der Wert des entsprechenden String bzw. mindestens eines davon nichtleer ist.

havemaskreasons, maskreasons, maskreasons*

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Für verfügbare Versionen gibt maskreasons die Gründe für Maskierungen aus, und havemaskreasons ob es solche Gründe gibt. Als Trenner werden FORMAT_MASKREASONS_LINESKIP und FORMAT_MASKREASONS_SEP benutzt; bei maskreasons* werden hingegen FORMAT_MASKREASONSS_LINESKIP und FORMAT_MASKREASONSS_SEP benutzt.

haveuse, use, use*, use0

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Für verfügbare Versionen gibt use die IUSE Variable aus. Für installierte Versionen gibt use die USE-Flags an, und ob sie gesetzt sind (der Inhalt von FORMAT_BEFORE_SET_USE, FORMAT_AFTER_SET_USE, FORMAT_BEFORE_UNSET_USE, FORMAT_AFTER_UNSET_USE wird an den entsprechenden Stellen ausgegeben). Die use*-Variante berücksichtigt USE_EXPAND-Variablen separat und gibt sie unter Berücksichtigung der entsprechenden Variablenwerte von FORMAT_BEFORE_USE_EXPAND_START, FORMAT_BEFORE_USE_EXPAND_END, FORMAT_AFTER_USE_EXPAND, FORMAT_BEFORE_IUSE_EXPAND_START, FORMAT_BEFORE_IUSE_EXPAND_END bzw. FORMAT_AFTER_IUSE_EXPAND an den entsprechenden Stellen aus. Die use0-Variante unterdrückt die Ausgabe der USE_EXPAND-Variablen. haveuse kann benutzt werden, um zu testen, ob die Ausgabe nichtleer ist (in diesem Fall ist die Ausgabe 1, sonst leer).

requireduse, haverequireduse

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Für verfügbare Versionen gibt es die REQUIRED_USE-Variable aus, bzw. 1 falls diese Variable nicht leer ist. Die Expansion ist leer, falls REQUIRED_USE=true nicht gesetzt ist (oder bei der Erzeugung der Datenbank nicht gesetzt war).

date:VAR

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Es gibt die Installationszeit aus; das strftime()-Format für die Zeit wird aus der Variablen VAR genommen.

version,plainversion,revision

Dies darf nur in VARIABLE im Zusammenhang von Versionsausgaben benutzt werden. Es ist die reine Versionsnummer (man 5 ebuild: $PVR) als Text. Bei plainversion with die Versionsnummer ohne Revisionsnummer ausgegeben ($PV), und bei revision nur die Revisionsnummer ($PR). Im Gegensatz zu Portage ist die Revision leer, wenn keine spezifiziert ist.

installed, best, best*

Ist 1 oder leer, je nachdem of mindestens eine Version des Pakets installiert ist oder eine beste stabile bzw. instabile Version hat.

versionlines

Ist 1 oder leer, je nachdem ob --versionlines aktiv ist.

slotsorted

Ist 1 oder leer, je nachdem ob --versionsort aktiv ist.

color

Ist 1 oder leer, je nachdem, ob Farben/Markers ausgegeben werden. Falls beispielsweise die Ausgabe auf ein Terminal erfolgt und keine anderweitige Option angegeben wurde, ist die leer.

setnames, allsetnames

Die Namen aller lokalen Sets, zu denen das Paket gehört, durch Leerzeichen separiert. Mit allsetnames können auch "system" und "profile" dabei sein.

binary

Ist 1 oder leer, je nachdem, ob mindestens eine Version (verfügbar oder installiert) eine *.tbz2 Datei besitzt. Vgl. die Bemerkungen zu --binary.

mainrepo

Ist 1 oder leer, je nachdem, ob mindestens eine verfügbare Version zum Hauptrepository 0 (typischerweise: gentoo) gehört.

overlaykey, overlayname

Falls alle Versionen zum selben Overlay gehören, wird "[overlaykey]" (in entsprechenden Farben) bzw. "overlaylabel" ausgegeben.

havevirtual, havenonvirtual

Ist 1 or leer, je nachdem ob mindestens eine verfügbare Version aus einem (nicht)virtuellen Overlay stammt.

system

1, falls das Paket zu @system gehört.

profile

1, falls das Paket zu @profile gehört.

world

1, falls das Paket zur world-Datei gehört.

world_sets

1. falls das Paket zu world_sets gehört.

marked

1, falls der Paketname mit der --pipe-Option übergeben wurde (unabhängig davon, ob eine verfügbare Version auf die Maske passt, siehe havemarkedversion) Dies ist hauptsächlich für Tests sinnvoll.

havemarkedversion

1 oder leer, je nachdem ob mindestens eine verfügbare Version des Pakets markiert ist. Es ist möglich, dass ein Paket markiert wurde, obwohl keine der verfügbaren Versionen markiert wurden.

slots, slotted

1, falls es mindestens zwei Slots bzw. mindestens einen nichttrivialen Slotnamen gibt.

colliuse, colliuse*, colliuse0, havecolliuse

Die gesammelten IUSE-Flags (d.h. ihre Vereinigung) aller verfügbaren Versionen des Pakets, durch Leerzeichen separiert. Die Variante colliuse* gibt die USE_EXPAND-Variablen separat aus und benutzt dabei FORMAT_BEFORE_COLL_EXPAND_START, FORMAT_BEFORE_COLL_EXPAND_END und FORMAT_AFTER_COLL_EXPAND an den entsprechenden Stellen. Die Variante colliuse0 vermeidet die Ausgabe von USE_EXPAND-Variablen. havecolliuse ist 1, falls colliuse nichtleer ist; dies ist schneller als colliuse.

havebest, havebest*

1, falls das Paket eine beste stabile/instabile Version hat.

upgrade, upgradeorinstall, downgrade, recommend, recommendorinstall

upgrade ist 1, falls das Paket installiert ist und mindestens ein Slot ein Upgrade ermöglicht (oder die beste stabile Version ist eine neuer Slot und UPDATE_TO_HIGHEST_SLOT ist gesetzt). Die anderen Variablen testen analog, ob für das Paket ein Upgrade oder frische Installation möglich ist, ob ein Downgrade nötig ist, ob ein Up- oder Downgrade möglich/nötig ist, bzw. ob ein Up- oder Downgrade oder Frischinstallation nötig/mölich ist. Die Variable RECOMMEND_LOCAL_MODE entscheidet, ob diese Tests LOCAL_PORTAGE_CONFIG beachten.

bestupgrade, bestupgradeorinstall, bestdowngrade, bestrecommend, bestrecommendorinstall

Wie oben mit dem Unterschied, dass nur die beste stabile Version des Pakets beachtet wird (und nicht alle Slots).

better, worse, differ, bestbetter, bestworse, bestdiffer

Dies kann nur in Konditionaltests für DIFF_FORMAT_CHANGED benutzt werden. better ist 1, falls das neue Paket einen neuen Slot oder eine besssere stabile Version (or die gleiche beste stabile Version, aber von einem anderen Overlay) für einen Slot als das alte Paket hat. worse bedeutet analog, dass das alte Paket mindestens einen besseren Slot hatte oder einen Slot, den es im neuen Paket nicht gibt. differ bedeutet, dass nicht alle besten stabilen Slots des alten und neuen Pakets übereinstimmen. Die entsprechenden best*-Versionen haben eine analoge Bedeutung mit dem Unterschied, dass nur die beste stabile Version berücksichtigt wird (und nicht alle Slots). Die Variable RECOMMEND_LOCAL_MODE entscheidet, ob diese Tests LOCAL_PORTAGE_CONFIG beachten.

old..., new...

Dies kann nur in DIFF_FORMAT_CHANGED benutzt werden. Jedem Eigenschaftsname kann ein old oder new vorangestellt werden, und der Wert entspricht dieser Eigenschaft, wobei die alten bzw. neuen Daten benutzt werden. Falls weder old noch new angegeben ist, wird die neue Version angenommen. Beispielsweise gibt oldavailableversions:VAR die vorerigen verfügbaren Versionen aus (mit der Variablen VAR als Ausgabeformat), während newavailableversions:VAR und availableversions:VAR jeweils die verfügbaren Versionen des aktuellen (d.h. neuen) Pakets ausgeben.

 

Escape-Folgen

\\n \\r \\t \\b \\a

Diese werden auf die übliche Art wie in printf interpretiert. Innerhalb von FORMATSTRING werden Tabs in Leerzeichen umgerechnet, wobei unterstellt wird, dass der FORMATSTRING in UTF8 kodiert ist.

\\C<SPALTE>

Diese spezielle Escape-Folge ist nur in FORMATSTRING zulässig. Hierbei ist SPALTE eine Zahl (die eingeklammert sein muss). Während der Ausgabe, wird das Ganze von eix folgendermaßen interpretiert: Falls die Spalte SPALTE noch während der Ausgabe der aktuellen Zeile noch nicht erreicht wurde, werden so viele Leerzeichen ausgegben, dass dies der Fall ist. In gewissem Sinne kann dies also als ein mächtiger Tabulator betrachtet werden, dessen Interpretation nicht dem Terminal überlassen wird. For die Berechnung der aktuellen Zeichenposition in der Zeile wird unterstellt, dass der FORMATSTRING in UTF8 kodiert ist.

 

Farben

(COLORSTRING|COLORSTRING|...)

Der tatsächlich ausgewählte COLORSTRING hängt von COLORSCHEME? ab. Er sollte die folgende Gestalt haben:

MARKER_ODER_COLOR;MARKER_ODER_COLOR;...

MARKER_ODER_COLOR ist entweder ein Markername oder ein Farbname, optional gefolgt von ,1 (oder ,0) für (nicht-)helle Farbwahl.

Verfügbare Markernamen: none bold italic underline blink inverse

Verfügbare Farbnamen: default black red green yellow blue purple cyan gray 0 ... 255

Beachten Sie, dass gray geht nicht auf allen Terminals das Gewünschte tut, und die Farbnamen 0 ... 255 nur auf einem 88/256-Farben-Terminal sinnvoll interpretiert werden.

Die erste Farbe in COLORSTRING legt die Vordergrund-, die zweite die Hintergrundfarbe fest.

Wenn eine Vordergrundfarbe festgelegt wird, werden alle Farben und Marker zurückgesetzt. Der Leerstring ist als die Farbe "default" definiert. Insbesondere bewirkt (), dass alle Farben und Marker zurückgesetzt werden.

Falls weder Ausgabe noch ein Reset gewünscht ist, kann man den Markennamen (none) wählen.

 

Beispiele:

eix --format '{installed}(yellow,1;underline){else}(yellow,0){}<name>()\n' ...

Falls das Paket ... installiert ist, wird der Name unterstrichen in Hellgelb ausgegeben, sonst in normalem Gelb.

INSTFORMAT='{first}:{}<version> <date:DATEFORMAT>{!last}\n\t{}' DATEFORMAT='%x' eix --format '<category>/<name><installedversions:INSTFORMAT>\n' 'autom*'

Gibt für jedes autom*-Paket den Kategoriennamen aus sowie, wenn das Paket installiert ist, die installierten Versionen und die Installationstag. Man hätte das selbe Ergebnis auch durch Ersetzen von {!last}\t\n{} durch {first}:{else}\t\n{} erreichen können, weil es natürlich auf dasselbe hinausläuft, ob \t\n am Ende jeder Version mit Ausnahme der letzten oder am Anfang jeder Version mit Ausnahme der ersten ausgegeben wird.

FORMAT='{downgrade}%{FORMAT_ALL}{}' eix -I

Ausgabe aller installierten Pakete, für die es Downgrade-Empfehlungen gibt. Beachte, dass FORMAT='{downgrade}%{FORMAT}{}' nicht funktioniert, denn dies wäre eine selbstreferenzierende Definition bei der verspäteten Ersetzung: Natürlich kann eine Variable nicht durch eine Ersetzung durch sich selbst expandiert werden. Aus diesem Grund ist der Inhalt der Variablen FORMAT und ähnlicher Variablen sei eix-0.13.4 sehr einfach: Es ist einfach %{FORMAT_ALL} (und analog für andere Variablen). Daher kann man einfach die vollständige Definition des ursprünglichen Werts von FORMAT einfügen (was wir in obigem Beispiel getan haben).

Für kompakte Ausgabe ist es in obigem Beispiel nicht möglich, einfach die Option -c zu benutzen, denn die Benutzung dieser Option hat nur den Effekt, dass für den Formatstring die Variable FORMAT_COMPACT statt FORMAT benutzt wird. Für kompakte Ausgabe muss man also entweder

FORMAT_COMPACT='{downgrade}%{FORMAT_ALL_COMPACT}{}' eix -Ic

benutzen, oder einfacher und mit dem gleichen Effekt:

FORMAT='{downgrade}%{FORMAT_ALL_COMPACT}{}' eix -I

Eine viel einfachere Möglichkeit, die Selbstreferenz zu umgehen, ist in obigem Beispiel die Benuzung der --format Option:

eix --format '{downgrade}%{FORMAT}{}' -I

bzw. für kompakte Ausgabe

eix --format '{downgrade}%{FORMAT_COMPACT}{}' -I

 

DATEIEN

 

/etc/eix-sync.conf

Diese Datei enthält Kommandos und Konfigurationen für eix-sync. Kommentarzeilen beginnen mit #. Die Zeilen haben die folgende Gestalt und werden in der gegebenen Reihenfolge vor emerge --sync ausgeführt.

Beachten Sie, dass der Inhalt der Variablen EIX_SYNC_CONF an diese Datei angehängt wird. Per Vorgabe expandiert die Variable zu EIX_SYNC_OPTS, so dass effektiv auch diese Variable an die Datei angehängt wird. Beide Variablen können benutzt werden, um die Einstellungen aus /etc/eix-sync.conf zu modifizieren. Machen Sie sich bitte bewusst, dass der Code dieser Zeilen bei eix-sync innerhalb einer Shell mit "eval" ausgeführt wird, also Vorsicht bzgl. Sicherheitsproblemen!

Option(en)

Die Option(en) werden als Standardeinstellung für eix-sync ausgeführt (vor allen anderen Optionen). Wie üblich muss Option(en) mit "-" beginnen. option(en) wird von der Shell mit "eval" ermittelt: Daher also Vorsicht bzgl. Sicherheit! Quoten von Shell-Commando-Trennern ist ebenfalls geboten.

Name

Ruft layman -s Name auf (<layman> ist Teil des Pakets app-portage/layman und dient zum Syncen von Overlays).

*

Ruft layman -S auf (d.h. alle Overlays werden mit layman gesynct).

!Kommando

Ruft eval Kommando innerhalb des eix-sync Shellskripts auf (in der selben Shell). Kommando muss erfolgreich beendet werden, sonst gibt eix-sync eine Warnung aus. (Folglich ist !layman Name mehr oder weniger äquivalent zu Name.) Es ist möglich das Kommando beispielsweise mit "; true" zu beenden, falls der Exit-Status ignoriert werdne soll. Mit der Option -F wird aus der Warnung sogar ein fataler Fehler. Durch Setzen von FATAL_HOOKS auf einen nichtleeren/leeren Wert kann der Effekt von -F für alle anschließenden Hooks erzwungen/aufgehoben werden. Falls nur der aktuelle Hook mit einem Fehler beendet werden soll, kann man explizit die aufrufen.

Man kann dieses Feature benutzen um z.B. einen Overlay vor dem Aufruf von layman zu entpacken oder um lokale Fixes auszuführen, nachdem layman aufgerufen wurde. Hier kann auch die Variable have_changed=: gesetzt werden, um eix-sync mitzuteilen, dass ein Overlay verändert wurde: Andernfalls wird eix-sync mit Exitstatus 3 anhalten, falls der Hauptbaum nicht verändert wurde.

Im Gegensatz zu früheren eix-Versionen gibt, Kommando nichts aus (mit einfo kann man Ausgabe erreichen), und Kommando wird nicht in einer Subshell ausgeführt, d.h. man kann auch Environmentvariablen modifizieren or eine Ausgabeumleitung starten/beenden. Der Nachtiel ist, dass man auch leicht versehentlich interne eix-sync-Variablen oder -Funktionen überschreiben kann; im Zweifelsfall ist es daher besser, dass Kommando in runde Klammern zu packen (...) um es in einer Subshell auszuführen.

!!Kommando

Die ist ähnlich zu ! Kommando mit dem Unterschied, dass Kommando immer ausgeführt wird, d.h. selbst wenn die Optionen -d, -u oder -l benutzt wird. Es ist dazu gedacht, Environmentvariablen für andere Programme zu setzen.

~Kommando

Dies ist nur für die eix-sync-Optionen -s oder -2 wichtig. In diese Fall wird Kommando vor dem ersten Aufruf von rsync ausgeführt; die Ausgabe von Kommando wird innerhalb der eix-sync Shell mit "eval" ausgeführt. Falls Kommando oder die das "eval" der Ausgabe nicht erfolgreich sind, wird eix-sync eine Warnung ausgeben (oder einen Fehler, falls -F aktiv ist, d.h. wenn FATAL_HOOKS nichtleer ist). Dies kann benutzt werden um beispielsweise keychain auszuführen oder den Inhalt einer ~/.keychain/*-sh-Datei oder export-Kommandos für die aktuellen SSH_AUTH_SOCK und SSH_AGENT_PID auszugeben. Es ist ebenfalls zulässig, dass die Ausgabe von Kommando ein Kommando ist, das die Variablen PORTAGE_RSYNC_OPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR, PORTDIR_SERVER, PORTDIR_CLIENT, SERVER oder CLIENT modifiziert. Diese variables werden mit Standardvorgaben gefüllt, wenn Kommando aufgerufen wird und werden später im rsync Kommando mit ihrer offensichtlichen Bedeutung benutzt.

@Kommando

Fügt einen Hook für Kommando hinzu; die tatsächliche Ausführung von Kommando wird zurückgestellt, bis emerge --sync (erfolgreich) ausgeführt wurde.

@@Kommando

Fügt einen Hook für Kommando hinzu; die tatsächliche Ausführung von Kommando wird zurückgestellt, bis emerge --sync und das darauffolgende eix-update (erfolgreich) ausgeführt wurde.

Es folgt ein schematischer Überblick über die Reihenfolge der Hooks/Kommandos:

!! hooks

cp /var/cache/eix/portage.eix /var/cache/eix/previous.eix

layman-Aufrufe und !-Hooks in der Reihenfolge von /etc/eix-sync.conf

~ hooks

emerge --sync

@ hooks

eix-update

@@ hooks

eix-diff

Einige Beispiele nützlicher Zeilen in /etc/eix-sync.conf:

-F

Stets ein Fehlerabbruch, falls layman/hook fehlschlägt. Dies war bei früheren eix versionen stets der Fall.

-C --ignore-default-opts

Diese Zeile sollte benutzt werden, falls --ask in EMERGE_DEFAULT_OPTS in /etc/portage/make.conf steht, so dass keine Rückfrage für eix-sync erfolgt.

-r -M

Dies ist nüztlich bei PORTDIR_CACHE_METHOD=assign, falls FEATURES=metadata-transfer inaktiv oder ausgeschaltet ist (Letzteres ist bei neueren Portage-Versionen der Fall). Je nach Bedarf kann auch -r oder -M alleine angegeben werden. Oder man kann -M durch die Zeile

@StatusInfo...[Statuszeile]

Ankündigung, dass das nächste Kommando ... ist (Setzt die Statuszeile und gibt die Information für den Benutzer aus).

@Statusline...

Wie oben, setzt aber nur die Statuszeile.

@einfo...

Wie oben, gibt aber nur die Information für den Benutzer aus.

@eix-remote fetch1

Herunterladen der Remote1-Daten bei jedem Aufruf von eix-sync.

@emerge --regen

ersetzen, um emerge --regen statt emerge --metadata zu benutzen.

@egencache --repo=local --update

Updated den Metadaten-Caches des Overlays mit dem Repository-Namen "local" bevor eix-update aufgerufen wird, aber nach dem Aufruf von emerge --sync. Dies kann bei Benutzung der Cachemethode metadata-md5 oder metadata-flat für diesen Overlay sinnvoll sein, falls man sicher sein will, dass der Metadaten-Cache aktuell ist. Der Nachteil im Falle von metadata-flat ist, dass dieses egencache-Kommando auch dann ausgeführt wird, wenn "local" nicht verändert wurde (was für locale Repositories typisch ist).

!egencache --repo=foo --update

Updated den Metadaten-Cache des Overlays mit Repository-Namen "foo"; dies kann sinnvoll sein, falls vorher eine Zeile foo oder eine Zeile !Kommando zum Updaten von foo steht, um diese Repository (durch layman oder ein anderes Kommando) zu updaten, und falls die Cachemethode metadata-flat für diesen Overlay benutzt werden soll, obwohl der Metadaten-Cache kaputt oder nicht im Repository enthalten ist.

!!exec >/var/log/eix-sync.log ; chown portage: /var/log/eix-sync.log || true

Sendet die Ausgabe in eine log-Datei (mit korrekten Rechten). Das "true" am Ende sorgt für Weiterausführung selbst wenn "chown" fehlschlägt. Falls die Ausgabe des abschließenden eix-diff nicht umgeleitet werden soll, kann man dies kombinieren mit

@@exec >/dev/tty

Ausgabe von eix-diff auf das Terminal, selbst im Falle von Ausgabeumleitung.

@@exit 0

Keine Ausführung des abschließenden eix-diff.

!!export FORCE_USECOLORS=${FORCE_USECOLORS:-true}

Falls FORCE_USECOLORS nicht in der Environment anders gesetzt wurde, wird die eix-Ausgabe auch im Falle von Ausgabeumleitung farbig.

~keychain --quiet ~/.ssh/id_rsa ; cat ~/.keychain/`hostname`-sh

 

/etc/eixrc

Globale Konfigurations-Datei. Die variablen in ~/.eixrc oder von der Environment können die Variablen aus dieser Datei überschreiben, siehe ~/.eixrc.

 

EIXRC

Wenn diese Environmentvariable gesetzt ist, wird ihr Wert anstelle des Dateinamen /etc/eixrc benutzt, um die Konfigurationsdaten zu lesen. In diesem Fall wird die Datei ~/.eixrc ignoriert (aber sie kann natürlich ggf. gesourced werden).

 

EIX_SYNC_OPTS, EIX_SYNC_CONF, EIX_REMOTE_OPTS, EIX_LAYMAN_OPTS, EIX_TEST_OBSOLETE_OPTS

Obwohl diese Variablen typischerweise in ~/.eixrc gesetzt werden (und daher erst im nächsten Abschnitt beschrieben werden), werden diese Variablen hier hervogehoben, weil sie besonders sicherheitsrelevant sind: Sie (oder zumindest Teile von ihnen) werden durch die Shell ausgeführt, wenn die enstprechenden Skripte ausgeführt werden. Daher sollte man sicher gehen, dass diese Variablen nicht kompromittiert sind, wenn diese Skripte mit root-Rechten ausgeführt werden.

 

~/.eixrc

Benutzerspezifische Konfigurationsdatei. Die Variablen dieser Datei können durch Environmentvariablen überschrieben werden. In dieser Datei kann eine Shell-ähnliche Syntax benutzt werden, um die folgenden Variablen zu setzen. Insbesondere können andere Dateien gesourced werden und Hilfsvariablen benutzt werden um andere Variablen zu setzen.

Dabei ist jedoch zu beachten, dass bei der überlichen Benutzung von Hilfsvariablen nur die Ergebnisse bei --dump oder --dump-defaults angezeigt werden, und man kann die eingesetzten Werte nicht durch Environmentvariablen abändern.

Aus diesem Grund gibt es neben der Shell-üblichen Derefenzierung von Variablen auch eine weitere Möglichkeit der Dereferenzierung mit der Syntax %{VARIABLE} (the Klammern hier sind nicht-optional). Diese Syntax bedeutet, dass die Ersetzung so lange verzögert wird, bis alle Konfigurationsdateien und Environmentvariablen gelesen werden, und die Ersetzung wird bei --dump oder --dump-defaults nicht durchgeführt.

Dieses Konzept wird verzögerte Ersetzung/Referenz genannt, und es bietet einige zusätzliche Features:

Specielle Symbole zur verzögerten Ersetzung

%{%

Dies muss benutzt werden, falls %{ im Variablentext stehen soll (sonst würde verzögerte Ersetzung aktiv).

*VARIABLE

Falls die verzögerte Referenz eine Variablennamen benutzt, der mit * beginnt, so wird dieses * durch EIX_, DIFF_, UPDATE_ oder DROP_ ersetzt, je nachdem ob es von eix/eix-diff/eix-update bzw. eix-drop-permissions benutzt wird. Auf diese Weise kann man verschiedene Standardeinstellungen für diese Programme festlegen.

Beispielsweise wird die verzögerte Referenz %{*VARIABLE} die Expansion der Variablen EIX_VARIABLE, DIFF_VARIABLE, UPDATE_VARIABLE bzw. DROP_VARIABLE einfügen.

Die \- und *-Attribute können kombiniert werden (die Reihenfolge spielt keine Rolle), und sie können auch mit einem APPENDIX kombiniert werden.

Ein praktisches Beispiel: Falls EIX_USER den Wert "nobody" haben soll, falls es von eix-drop-permissions (also etwa durch eix-remote) aufgerufen wird, aber den Vorgabewert "portage" in allen anderen Fällen, kann man folgendes Setzen:

EIX_USER=%{*EIX_USER}

EIX_EIX_USER=portage

DIFF_EIX_USER=portage

UPDATE_EIX_USER=portage

DROP_EIX_USER=nobody

\VARIABLE

Falls eine verzögerte Referenz einen Variablennamen benutzt, der mit \ beginnt, so werden alle \ or [\n\r\t ] Zeichen des (expandierten) Inhalts von VARIABLE als escaped betrachtet.

Insbesondere kann die verzögerte Referenz %{\VARIABLE} in Stiring-List-Variablen wie CACHE_METHOD oder EIX_LOCAL_SETS benutzt werden und stellt dabei sicher, dass VARIABLE höchstens einen Eintrag "so wie er ist" erzeugt, selbst dann, wenn dieser Eintrag Leerzeichen oder des Zeichen \ enthält.

Die \- und *-Attribute können kombiniert werden (die Reihenfolge spielt keine Rolle), und sie können auch mit einem APPENDIX kombiniert werden.

*VARIABLE APPENDIX

Dies wird nur dann erkann, wenn APPENDIX mit einem der Zeichen , oder ; beginnt. In diesem Fall wird APPENDIX and den Inhalt von VARIABLE angehängt sowie vor jedes |-Zeichen dieses Inhalts. (Der APPENDIX kann mit den \- und *-Attributen kombiniert werden.) APPENDIX wird unverändert übernommne, und er darf nicht das Zeichen } enthalten. Der Zweck ist es, das Schreiben von Farben zu vereinfachen. Beispiel:

COLOR_DEFAULT=blue|27

FORMAT="(%{COLOR_DEFAULT,1)A (%{COLOR_DEFAULT;invert})B"

BAD_FORMAT=(%{COLOR_DEFAULT},1;invert)A

In diesem Beispiel wird FORMAT zu

(blue,1|27,1)A (blue;invert|27;invert)B

expandieren, BAD_FORMAT hingegen zu

(blue|27,1;invert)A

Letzteres führt wahrscheinlich nicht zum beabsichtigten Ergebnis, falls COLORSCHEME?=0 ist.

Konditionelle Blocks in verögerten Referenzen

Falls einige Variableninhalte in Abhängigkeit einer (Booleschen) Variablen ganz anders aussehen sollen, können konditionelle Blocks benutzt werden.

Dies ist analog zu konditionellen Blocks im FORMATSTRING: Wenn die referenzierte Variable schließlich zum Booleschen Wert "true" expandiert (true/1/yes/y/on) (bzw. zu etwas Nichtleerem, falls VARIABLE ein zusätzliches ? vorangestellt wird), so ist das Ergebnis wahr, und der entsprechende Block des Strings wird expandiert. Konditionen können negiert werden, so dass der else-Teil expandiert wird, wenn die Bedingung wahr ist und der if-Teil, wenn die Bedingung falsch ist. Der else-Teil kann auch vollständig weggelassen werden. Die speziellen Variablennamen *VARIABLE (statt VARIABLE) können auch hier benutzt werden.

%{?VARIABLE}TCODE%{}

Expandiert zu TCODE, falls VARIABLE zu "true" expandiert.

%{??VARIABLE}TCODE%{}

Expandiert zu TCODE, falls VARIABLE zu einem nichtleeren String expandiert.

%{!VARIABLE}TCODE%{}

Expandiert zu TCODE, falls VARIABLE nicht zu "true" expandiert.

%{!?VARIABLE}TCODE%{}

Expandiert zu TCODE, falls VARIABLE zu einem leeren String expandiert.

%{?VARIABLE}TCODE%{else}FCODE%{}

Expandiert zu TCODE falls VARIABLE zu "true" expandiert, sonst zu FCODE.

%{??VARIABLE}TCODE%{else}FCODE%{}

Expandiert zu TCODE, falls VARIABLE zu einem nichtleeren String expandiert, sonst zu FCODE.

%{!VARIABLE}TCODE%{else}FCODE%{}

Expandiert zu TCODE, falls VARIABLE nicht zu "true" expandiert, sonst zu FCODE.

%{!?VARIABLE}TCODE%{else}FCODE%{}

Expandiert zu TCODE, falls VARIABLE zu einem leeren String exapndiert, sonst zu FCODE.

Ein konditioneller Block muss vollständig in einer einzigen Variable stehen, d.h. es ist nicht möglich, beispielsweise das %{} Zeichen aus einer anderen Variable über verzögerte Ersetzung zu erhalten (aber in TCODE/FCODE können wiederum verzögerte Referenzen enthalten sein).

Beachten Sie, dass Variablen, die zu verzögerten Ersetzung benutzt werden, nur dann mit --dump ausgegeben werden, wenn sie tatsächlich benutzt werden (d.h. in einer anderen Variable dereferenziert werden). Falls sie trotzdem ausgegeben werden sollen, etwa für Kommentare oder leichtere spätere Änderungen, so können Referenzen auf sie in der DUMMY-Variable gespeichert werden.

Die folgenden Variablenliste enthält nicht die Variablen, die in verspäteter Ersetzung benutzt werden. Um eine Beschreibung der Letzteren (und ihrer Vorgabewerte) zu erhalten, benutzen Sie bitte eix --dump.

Einige Bemerkungen zur Stabilität der Namen bzgl. zukünftiger eix-Versionen: Soweit möglich und sinnvoll, wird versucht, die Bedeutung aller Namen beizubehalten, zumindest für die im folgenden aufgezählten Variablen. Bei Variablen zur verspäteten Ersetzung sind Änderungen wahrscheinlicher. Als Faustregel gilt: Je "elementarer" eine Variable ist (beispielsweise eine Variable, die nur ein einzelnes Zeichen definiert), desto unwahrscheinlicher ist, dass Sie sich in zukünftigen eix Versionen ändert oder entfernt wird. Hingegen Variablen zur verzögerten Ersetzung im "Mittelbau" (die also wiederum selbst andere Variablen zur verzögert Ersetzung benutzen), haben eine größere Wahrscheinlichkeit in zukünftigen eix-Versionen in ihrere Bedeutung geändert oder entfernt zu werden - je nachdem, welche Erweiterungen im Format für gewisse zukünftige Erweiterungen von eix notwendig sein werden.

DUMMY (string)

Diese Variable hat keinen direkten Einfluss auf das Programm, aber ihr Inhalt kann benutzt werden, um verzögerte Ersetzungen zu (ansonsten unbenutzten) Variablen zu sammeln, so dass diese mit --dump oder --dump-defaults ausgegeben werden.

WIDETERM (true/false/auto/leer)

Diese Variable wird nur zur verzögerten Ersetzung benutzt. Sie legt fest, ob ein breites Terminal (breiter als 80 Spalten) vorliegt. Falls WIDETERM leer oder auto ist, wird COLUMNS benutzt, um den Wert zur verzögerten Ersetzung festzulegen.

COLUMNS (integer / auto / leer)

Dies legt die Terminalbreite fest, wenn WIDETERM leer ist. Wenn COLUMNS leer oder auto ist, wird eine Heuristik für WIDETERM benutzt. Wenn die Heuristik fehlschlägt ist der eingesetzte Wert von WIDETERM leer (was sich bzgl. verzögerter Ersetzung wie false verhält).

EIX_SYNC_OPTS, EIX_SYNC_CONF (string)

Der Inhalt von EIX_SYNC_CONF wird an die Datei @SYSCONFDIR/eix-sync.conf angehängt. Weitere Details finden sich in der Beschreibung jener Datei. Per default ist EIX_SYNC_CONF eine verzögerte Ersetzung von EIX_SYNC_OPTS, so dass typischerweise EIX_SYNC_OPTS zum gleichen Zweck genutzt werden kann. Vorsicht: Wenn eine dieser Variablen kompromittiert ist, kann beim Aufruf von eix-sync mit Root-Rechten nahezu alles passieren! Diese Variablen müssen im Falle einer Benutzung vorsichtig gequotet werden.

EIX_REMOTE_OPTS, EIX_LAYMAN_OPTS, EIX_TEST_OBSOLETE_OPTS (string)

Der Inhalt dieser Variablen wird einem "eval" unterzogen und als Argumente für die Skripte eix-remote, eix-layman bzw. eix-test-obsolete benutzt. Diese Variablen sind also vorsichtig zu quoten. Vorsicht vor Sicherheitsrisiken!

EIXRC_SOURCE (string)

Dieser Pfad wird bei Source-Kommandos in /etc/eixrc vorangestellt. Er ist gedacht, in der Environment gesetzt zu werden, aber er kann auch in /etc/eixrc gesetzt werden. Im letzte Fall wird er alle Settings aus der Environment überschreiben, sobald er gelesen wird, so lange bis alle Dateien gesourced wurden. Beachten Sie, dass noch keine verzögerte Ersetzung stattfindet, wenn diese Variable aktiv wird.

EIX_PREFIX (prefix-string) (prefix-string heißt, dass dies ein String ist, aber wenn es den Wert '/' hat, wird dieser geändert zu '')

Dies ist i.W. dazu gedacht in der Environment gesetzt zu werden, falls eine chroot benutzt wird: Es wird dem Pfad vorangestellt, in dem /etc/eixrc gesucht wird. Falls es nicht gesetzt ist, wird der Wert der Environment-Variable PORTAGE_CONFIGROOT vorangestellt. Der Vorgabewert (typischerweise leer) dieser Variable wird benutzt, falls keines von beiden in der Environment gesetzt ist.

Darüberhinaus wird dieser Variable in der verzögerten Ersetzung benutzt, um den Präfix einer Menge von Pfaden der folgenden Variablen zu setzen; mit eix --dump erfährt man im Detail, in welchen anderen Variablen sie vorkommt.

EPREFIX (prefix-string)

Der Vorgabewert dieser Variable kommt von EIX_PREFIX, wobei ein zur Compilezeit angegebener Vorgabewert (für prefix-portage) angehängt wird. Diese Variable hat alleine keine Bedeutung, aber sie wird mit verzögerte Ersetzung benutzt, um den Präfix einer Reihe von Pfaden in den folgen Variablen festzulegen (wenn ihr Vorgabewert nicht geändert wird); mit eix --dump erfährt man im Detail, in welchen anderen Variablen sie vorkommt. In den derzeitigen Vorgabewerten beeinflusst sie alle Pfade mit den folgenden Ausnahmen:

TMPDIR (string)

Dies wird zur verzögerten Ersetzung in EIX_TMPDIR benutzt. eix exportiert diese Variable und initialisiert sie dabei auf den Wert von EIX_TMPDIR. Der Wert ist typischerweise durch die Environment gesetzt.

EIX_TMPDIR (string)

Wenn diese Variable nicht leer ist, wird dieses Verzeichnis statt /tmp für Temporärdateien benutzt. eix exportiert diese Variable als TMPDIR. Der voreingestellte Wert ist verzögerte Ersetzung durch TMPDIR.

/usr/bin/eix-functions.sh

~/.eixrc

Cachedateipfad(e) aus der Kommandozeile

PORTAGE_PROFILE (nur die variable, nicht der Link)

PORTDIR

Overlay-Pfade

Die letzten drei Punkte können durch EPREFIX_TREE modifiziert werden.

Der Zweck von EPREFIX ist es, eine quasi-chroot analog zu prefix-portage zu erlauben.

ROOT (prefix-string)

EPREFIX_TREE (prefix-string)

EPREFIX_ROOT (prefix-string)

Dies sind tatsächlich nicht interne Variablen von eix, sondern sie werden nur zur verzögerten Ersetzung für die folgenden Variablen analog zu EPREFIX benutzt (siehe oben).

Der Zweck von ROOT ist es, ungefähr Portage's Nutzung dieser Variablen wiederzuspiegeln. Beachte, dass die Variablen in /etc/portage/make.conf keinen Einfluss auf eixs Konfigurationsvariablen haben. Insbesondere wird ein Kommando ROOT=something in /etc/portage/make.conf keinen Einfluss auf eix haben. Es muss statt dessen in der Environment oder eine Konfigurationsdatei von eix gesetzt werden.

Man kann leicht konfigurieren, auf welche Pfade die Variablen EPREFIX oder ROOT Einfluss nehmen: Man muss in den entsprechenden folgenden Variablen nurr entsprechend die verzögerte Referenz %{EPREFIX}, %{ROOT}, nichts, oder %{EPREFIX_ROOT} benutzen. (Letzteres ist seinerseits als verzögerte Referenz definiert ist, so dass man leicht ändern kann was geschehen soll, falls EPREFIX und ROOT beide nichtleer sind: Man kann sie aneinandersetzen oder nur eines davon benutzen). Man kann natürlich auch andere Variablen zur verzögerte Ersetzung benutzen; beispielsweise könnte man

EIX_CACHEFILE=%{EPREFIX_PROFILE}/var/cache/eix/portage.eix

setzen, wenn man will, dass die Cachedatei von eix (nur) vom PROFILE-Wurzelverzeichnis abhängen soll.

PORTAGE_CONFIGROOT (prefix-string)

Dieser Pfad wir /etc-Pfaden vorangestellt. Der Zweck ist es, PORTAGE_CONFIGROOT auf analoge Weise wie portage zu berücksichtigen. Falls diese Variable in der Environment gesetzt wird, wird sie auch den Pfad ändern, in dem /etc/eixrc gesucht wird. (Beachte, dass das Lesen von /etc/eixrc geschieht, bevor verzögerte Ersetzung aktiv wird.)

MAKE_GLOBALS (string)

Falls diese Datei existiert, so wird sie anstelle von %{PORTAGE_CONFIGROOT}/etc/make.globals benutzt. Der Vorgabewert entspricht dem Verhalten von >=portage-2.2*

PORTAGE_REPOS_CONF (string)

Diese Datei wird zur Vorgabe der Repository-Informationen eingelesen. Erst danach wird /etc/portage/repos.conf berücksichtigt.

PORTAGE_REPOSITORIES (string)

Wenn diese Variable nichtleer ist, wird ihr Inhalt ähnlich wie von Portage anstelle aller repos.conf-Dateien benutzt.

EPREFIX_PORTAGE_EXEC (prefix-string)

Dieser Pfad kann als Präfix für /usr/bin/ebuild benutzt werden.

EPREFIX_SOURCE (prefix-string)

Dieser Pfad wird allen Pfaden vorangestellt, die als Argumente von Source-Kommandos in /etc/portage/make.conf und /etc/make.globals auftauchen.

EPREFIX_INSTALLED (prefix-string)

Die wird allen Pfaden vorangestellen, in den eix Informationen über installierte Pakete sucht.

EPREFIX_PORTAGE_CACHE (prefix-string)

Dieser Präfix wird dem Portage Cache vorangestellt.

EPREFIX_ACCESS_OVERLAYS (prefix-string)

Dieser Präfix wird Overlays vorangestellt, sobald auf ihre Dateien zugegriffen wird.

EPREFIX_PORTDIR (prefix-string)

Dieser Pfad wird PORTDIR vorangestellt.

EPREFIX_OVERLAYS (prefix-string)

Dieser Präfix wird allen Einträgen von PORTAGE_OVERLAY vorangestellt.

EPREFIX_PROFILE (prefix-string)

Dieser Präfix wird PORTAGE_PROFILE (die Variable, nicht der Link) vorangestellt.

EPREFIX_VIRTUAL (prefix-string)

Dies wir Overlays in der eix Datenbank bei Tests, ob sie existieren, vorangestellt.

EIX_CACHEFILE (string)

Die eix-Cachedatei, normalerweise %{EPREFIX}/var/cache/eix/portage.eix

EIX_PREVIOUS (string)

Die alte eix-Cachedatei für eix-diff und eix-sync, normalerweise %{EPREFIX}/var/cache/eix/previous.eix

EIX_REMOTE1, EIX_REMOTE1 (string)

Die eix-Cachedatei, die bei -R bzw. -Z benutzt wird. Falls der String nichtleer ist, benutzt eix-remote diese Datanbank zur Ausgabe. Der Vorgabewert ist %{EPREFIX}/var/cache/eix/remote.eix bzw. %{EPREFIX}/var/cache/eix/remote2.eix

REMOTE_DEFAULT (integer)

Der Wert 1, 2 oder 0 bedeutet, dass als Vorgabe die Option -R bzw. -Z bzw. weder noch aktiviert ist.

EIX_REMOTEARCHIVE1, EIX_REMOTEARCHIVE2 (string)

Eine lokale Kopie des Remote-Archivs, auf das eix-remote zugreift. Falls es leer ist, werden nur Temporärdateien benutzt.

EBUILD_DEPEND_TEMP (string)

Pfad zur Datei, die von ebuild depend generiert wird.

EIX_WORLD (string)

Die Datei, die eix als world-Datei betrachtet. Beachte, dass diese Datei normalerweise nur für Mitglieder der Gruppe portage lesbar ist. Um diese Privilegien zu vermeiden, kann SAVE_WORLD benutzt werden.

EIX_WORLD_SETS (string)

Die Datei, die eix als world_sets benutzt. Es gilt dasselbe wie für EIX_WORLD

EIX_LOCAL_SETS (Stringliste)(die Bedeutung von Stringliste wird im nächsten Absatz erklärt)

Dies ist eine Liste von Verzeichnissen, die lokal definierte Sets enthalten. Die Verzeichnisse werden in der gegebenen Ordnung gelesen; Dateien mit Setnamen, die früher gelesen wurden, werden ignoriert: In diesem Sinne haben frühere Einträge inEIX_LOCAL_SETS eine höhere Präzedenz.

Relative Verzeichnisse (d.h. solche, die nicht mit / beginnen) werden relativ zu $PORTDIR aufgefasst. Einträge in EIX_LOCAL_SETS, die mit dem speziellen Zeichen * beginnen, werden auf spezielle Art interpretiert: Sie werden als mehrere Einträge interpretiert, wobei das *-Zeichen die Pfade zu den Overlays in umgekehrter Ordnung durchläuft (umgekehrte Ordnung deswegen, weil in gewissem Sinne frühere Einträge in EIX_LOCAL_SETS spätere überschreiben, während man für PORTDIR_OVERLAY das Umgekehrte erwartet).

Die Vorgabe dieser Variable enthält /etc/portage/sets, /etc/portage/sets.eix, sets (d.h. ungefähr $PORTDIR/sets nach dem vorherigen Absatz), */sets (d.h. ungefähr $PORTIDR_OVERLAY/sets nach dem vorherigen Absatz) sowie %{EIX_LOCAL_SETS_ADD}. Der Grund für Letzteres ist, dass man einfach zusätzliche Verzeichnisse zur Variablen %{EIX_LOCAL_SETS_ADD} in /etc/eixrc hinzufügen kann. Gründe dafür sind beispielsweise, wenn man in /etc/portage/sets.conf oder in der sets.conf Datei eines Overlays ein weiteres multiset-Verzeichnis definiert, z.B. für einen Overlay oder für die Behandlung mit "world-candidate = False".

Für alle Stringlisten-Variablen sind die erlaubten Trenner zwischen verschiedenen Einträgen [ \t\r\n]. Falls solch ein Trenner innerhalb eines Eintrags benutzt werden soll, so kann man ihn durch Voranstellen von \ escapen. Natürlich müssen alle \-Zeichen analog escaped werden, weil Escapes von Escapes oder Trennzeichen entfernt werden. Falls eine Variable so, wie sie ist, als einzelner Eintrag eingefügt werden soll, kann man verzögerte Ersetzung benutzen: %{\VAR} wird den Wert der Variablen VAR einfügen, wobei alle Zeichen aus [\ \t\r\n] escaped werden (mehr Details stehen im Abschnitt zur verzögerten Ersetzung).

EAPI_REGEX

Dieser reguläre Ausdruck soll auf bekannte EAPIs in .ebuild-Namensanhängen haben, die gemäß GLEP 55 bekannt sein sollen. Es kann notwendig sein, diesen Ausdruck lokal entsprechend der installierten Portage-Version zu modifizieren (um sicherzugehen, dass die installierte Portage-Version die entsprechenden EAPIs parsen kann). Ein Ausnahmefall ist, wenn diese Variable leer ist: In diesm Fall werden alle ebuilds mit EAPI-Anhängen ignoriert.

SAVE_WORLD (true/false)

Falls dies gesetzt ist, werden die Informationen der world-Datei in /var/cache/eix/portage.eix gespeichert. Vorsicht: Dies bedeutet, dass jeder, der diese Datei lesen kann auch Informationen über die world-Datei hat!

CURRENT_WORLD (true/false)

Falls diese Variable falsch ist, wird die Information über die world-Datei aus /var/cache/eix/portage.eix benutzt, selbst dann, wenn die aktuelle world-Datei lesbar sein sollte. Andernfalls wird die aktuelle world-Datei (wenn sie lesbar ist), diese Information überschreiben.

EIX_USER, EIX_GROUP, EIX_UID, EIX_GID (string/integer)

eix, eix-diff, eix-update, eix-drop-permissions und eix-remote ändern so früh wie möglich ihre Rechte zu EIX_USER/EIX_GROUP (bzw. zu den ID-Zahlen EIX_UID/EIX_GID, falls die vorherigen Variablen keinen gültigen Namen enthalten). Um dies zu verhinden, kann ein ungültiger Namen (etwa der leere Name) und eine nicht-positive ID-NUmmer benutzt werden.

Falls EIX_GROUP gültig und EIX_GID positiv ist, dann wird auch die Gruppenlist nach der folgenden Regel geändert: Falls EIX_USER ein gültiger Name ist, wird die volle Gruppenliste dieses Benutzers gewählt; andernfalls schrumpft die Gruppenliste auf einen einzelnen Eintrag zusammen.

REQUIRE_DROP (true/false/root)

Der Wert true bedeutet, dass die Rechteänderungen entsprechend von EIX_{USER,GROUP,UID,GID} erfolgreich sein müssen, vgl. DROP_FATAL. Im Falle des Werts root muss dies nur dann der Fall sein, wenn die aktuelle UID den Wert 0 hat.

NODROP_FATAL (true/false)

Wenn die Voraussetzung entsprechend REQUIRE_DROP fehlschlägt, wird mit einem Fehler abgebrochen (true) bzw. nur eine Warnung ausgegeben.

PORTAGE_ROOTPATH (string)

Falls nichtleer, wird dies Variable unverändert an ebuild.sh für die Cachemethode ebuild* übergeben.

DEFAULT_ARCH (string)

Der Vorgabewert für ARCH, falls keiner im Profile spezifiert ist.

NOFOUND_STATUS (integer)

Dieser Wert wird als Exit-Status benutzt, falls kein Paket passt. Der Wert von COUNT_ONLY_PRINTED wird dabei berücksichtigt.

MOREFOUND_STATUS (integer)

Dieser Wert wird als Exit-Status für 2 oder mehr Treffer benutzt. Der Wert von COUNT_ONLY_PRINTED wird dabei berücksichtigt.

EIX_LIMIT, EIX_LIMIT_COMPACT (integer)

Als Sicherheitsmaßnahme für Vertipper werden auf dem Terminal niemals mehr als die entsprechende Anzahl von Paketen ausgegeben: Es gibt zwei verschiedene Variablen, je nachdem, ob --compact aktiv ist oder nicht. Es gibt keinen solchen Limit, falls die Ausgabe nicht auf das Terminal geht, oder falls die Variable den Wert 0 enthält.

QUICKMODE (true/false)

Bestimmt, ob für eix und eix-diff die Option --quick die Vorgabe ist.

CAREMODE (true/false)

Bestimmt, ob für eix und eix-diff die Option --care die Vorgabe ist.

USE_BUILD_TIME (true/false)

Entscheidet, ob der BUILD_TIME-Eintrag (falls existent) der Portage Datenbank benutzt werden kann anstelle des Zeitstempels des Verzeichnisses (das normalerweise die Installationszeit trägt). Der Unterschied ist für gewöhnlich nur für Pakete wichtig, die aus einem *.tbz2 installiert wurde, aber in den meisten Fällen ist die BUILD_TIME relevanter (und auch verlässlicher). Unglücklicherweise ist die BUILD_TIME nur für Pakete verfügbar, die mit >=portage-2.2_rc63 gebaut und installiert wurden. Der eix-installed [no-]buildtime Test kann herausfinden, für welche Versionen dies (nicht) der Fall ist. Die BUILD_TIME zu lesen ist stets langsamer als das Lesen des Zeitstempels der Verzeichnisses (selbst dann, wenn die BUILD_TIME nicht verfügbar ist). Daher kann es sinnvoll sein, diese Variable auf false zu setzen, wenn die Geschwindigkeit wichtiger ist als eine verlässliche BUILD_TIME-Information.

QUIETMODE (true/false)

Bestimmt, ob für eix und eix-diff die Option --quiet die Vorgabe ist.

PRINT_APPEND (string)

Dieser String wir an die Ausgabe von --print. Standard Escape-Sequences wie \n in diesem String werden interpretiert. Der default ist ein Zeilenvorschub, um in interaktiven Shells eine vernünftige Ausgabe zu erzeugen. Beachte, dass die Kommando-Ersetzung in Shellskripten Leerzeichen am Ende der Ausgabe entfernt, so dass dieser Zeilenvorschub nicht schadet (Leerzeichen/Zeilenvorschübe am Ende der Variable werden in Skripten ja ohnehin entfernt). Wenn man also in einem Shellskript Variablen von eix lesen will, ohne ev. deren Leerzeichen am Ende zu unterdrücken, sollte man ein sichtbares Zeichen für PRINT_APPEND benutzen, beispielsweise so etwas wie VAR=`PRINT_APPEND=x eix --print VAR` ; VAR=${VAR%x}

DEFAULT_FORMAT (normal/compact/verbose)

Legt fest, ob --compact oder --verbose als Vorgabe gewählt wird. Da diese Variable vom Benutzer in /etc/eixrc oder ~/.eixrc geändert werden kann, kann dies ungewünschte Nebenwirkungen auf Skripte haben, die FORMAT mit der Intention setzen, einen festen FORMATSTRING vorzugeben: Solche Skripte sollten besser die --format Option benutzen (die seit eix-0.29.6 DEFAULT_FORMAT ignoriert), die --normal Option benutzen (die seit eix-0.29.6 existiert) und/oder DEFAULT_FORMAT=normal exportieren.

DIFF_ONLY_INSTALLED (true/false)

Legt fest, ob eix-diff nur Versionsänderungen installierter Pakete betrachtet.

DIFF_NO_SLOTS (true/false)

Legt fest, ob eix-diff Slots für Versionsänderungen betrachtet.

DIFF_SEPARATE_DELETED (true/false)

Legt fest, ob eix-diff gelöschte Pakete getrennt auflistet. Andernfalls wird eix-diff gelöschte und geänderte Pakete "alphabetisch" auflisten.

NO_RESTRICTIONS (true/false)

Falls nicht gesetzt, werden keine RESTRICTION- und PROPERTIES-Daten ausgegeben.

RESTRICT_INSTALLED (true/false)

Legt fest, ob fetch- und mirror-Restriktionen installierter Pakete beachtet werden sollen.

CARE_RESTRICT_INSTALLED (true/false)

Legt fest, ob fetch- und mirror-Restriktionen installierter Versionen stets von Disk gelesen werden sollen, selbst dann wenn sie von einer entsprechenden verfügbaren Version bekannt sind. Dies ist langsamer, aber zuverlässiger, d.h. es wird auch herausfinden, ob sich die Restriktionen geändert haben.

DEPS_INSTALLED (true/false)

Legt fest, ob Abhängigkeitsinformationen installierter Versionen stets von Disk gelesen werden sollen, selbst dann wenn sie von einer entsprechenden verfügbaren Version bekannt sind. Die Option --deps-installed tut dasselbe.

DEP (true/false)

Dieser Wert entscheidet, ob die Werte der Variablen DEPEND, RDEPEND, PDEPEND, BDEPEND (die z.B. mit eix -lv gezeigt werden könnten) tatsächlich benutzt und gespeichert werden sollen. Im positiven Fall verdoppelt sich ungefähr der Disk- und Speicherbedarf von eix.

SRC_URI (true/false)

Dieser Wert entscheidet, ob die Variable SRC_URI (die z.B. mit eix -lv gezeigt werden könnten) tatsächlich benutzt und gespeichert werden sollen. Im positiven Fall verdoppelt sich ungefähr der Disk- und Speicherbedarf von eix.

REQUIRED_USE (true/false)

Dieser Wert entscheidet, ob die Variable REQUIRED_USE (die z.B. mit eix -l gezeigt werden könnte) tatsächlich benutzt und gespeichert werden sollen. Im positiven Fall erhöht dich der Disk- und Speicherbedarf von eix.

FORMAT, FORMAT_COMPACT, FORMAT_VERBOSE (string)

Das normale, kompakte bzw. ausführliche Layout für die Ausgabe von eix. Siehe FORMATSTRING. Wenn eine dieser Variablen in einem Skript gesetzt wird, empfiehlt es sich, gleichzeitig den entsprechenden Wert für DEFAULT_FORMAT zu setzen.

Seit eix-0.13.4 expandieren diese Variablen als Vorgabe über verzögerte Ersetzung zu den Variablen FORMAT_ALL, FORMAT_ALL_COMPACT bzw. FORMAT_ALL_VERBOSE. Der Zweck dieser einfachen Definition ist, dass es leicht ist, auf die Vorgabedefinitionen mit verzögerter Ersetzung zu verweisen, wenn die Definition von FORMAT geändert werden soll.

FORMAT_TEST_OBSOLETE (string)

Das Format, das vom Script eix-test-obsolete benutzt wird; der Vorgabewert ist die verzögerte Ersetzung von FORMAT_ALL_COMPACT. Es ist nicht erlaubt here verzögerte Ersetzung von FORMAT zu benutzen; falls dies gewünscht ist, sollte man statt dessen die verzögerte Ersetzung von FORMAT_ALL benutzen.

DIFF_FORMAT_NEW, DIFF_FORMAT_DELETE, DIFF_FORMAT_CHANGED (string)

Diese Variablen werden nur von eix-diff benutzt. Sie beschreiben das Format für Pakete die neu sind, entfernt wurden, oder für die sich die höchste stabile Version geändert hat. Siehe FORMATSTRING. Seit eix-0.13.4 expandieren diese Variablen als Vorgabe über verzögerte Ersetzung zu den Variablen DIFF_FORMAT_ALL_NEW, DIFF_FORMAT_ALL_DELETE bzw. DIFF_FORMAT_ALL_CHANGED.

FORMAT_INSTALLATION_DATE, FORMAT_SHORT_INSTALLATION_DATE

Das strftime()-Format für die Ausgabe der Installationszeit (in normaler bzw. kurzer Form).

FORMAT_INSTALLED_USE

Ein printf-ähnliche Format zur Ausgabe von Useflags installierter Pakete. Wenn dieser String leer ist, ist die Ausführung etwas schneller, weil diese Daten dann nicht gelesen werden.

FORMAT_BEFORE_SET_USE, FORMAT_AFTER_SET_USE, FORMAT_BEFORE_UNSET_USE, FORMAT_AFTER_UNSET_USE

Diese Strings werden vor/nach gesetzten/ungesetzten USE-Flags installierter Versionen ausgegeben.

FORMAT_BEFORE_USE_EXPAND_START, FORMAT_BEFORE_USE_EXPAND_END, FORMAT_AFTER_USE_EXPAND, FORMAT_BEFORE_IUSE_EXPAND_START, FORMAT_BEFORE_IUSE_EXPAND_END, FORMAT_AFTER_IUSE_EXPAND

Diese String werden zu Beginn/Ende bzw. nach USE_EXPAND-Variablen bei use* für installierte bzw. verfügbare Versionen ausgegeben.

FORMAT_BEFORE_COLL_EXPAND_START, FORMAT_BEFORE_COLL_EXPAND_END, FORMAT_AFTER_COLL_EXPAND

Diese String werden zu Beginn/Ende bzw. nach USE_EXPAND-Variablen bei colliuse* ausgegeben.

FORMAT_MASKREASONS_LINESKIP, FORMAT_MASKREASONS_SEP, FORMAT_MASKREASONSS_LINESKIP, FORMAT_MASKREASONSS_SEP

Diese String werden als Trenner für neue Zeilen bzw. neue Gründe bei <maskreasons> bzw. <maskreasons*> ausgegeben.

COLOR_OVERLAYKEY, COLOR_VIRTUALKEY, COLOR_KEYEND, COLOR_OVERLAYNAME, COLOR_OVERLAYNAMEEND, COLOR_NUMBERTEXT, COLOR_NUMBERTEXTEND

Diese Farben werden vor/nach normalen/virtualen Overlaynummern benutzt, zur Ausgabe der Overlays am Ende bzw. zur Ausgabe der Anzahl der Pakete.

NOCOLORS (true/false)

Keine Benutzung von Farbsequenzen.

NOSTATUSLINE (true/false)

Kein Update der Statuszeile.

NOPERCENTAGE (true/false)

Keine Prozent-Fortschrittsanzeige.

FORCE_COLORS (true/false)

Benutzung von Farbsequenzen, selbst wenn stdout kein Terminal ist.

FORCE_STATUSLINE (true/false)

Update der Statuszeile, selbst wenn stdout kein passendes Terminal ist.

FORCE_PERCENTAGE (true/false)

Ausgabe der Prozent-Fortschrittsanzeige, selbst wenn stdout kein Terminal ist.

STYLE_VERSION_SORTED (true/false)

Legt fest, ob --versionsort als Vorgabe aktiv ist.

STYLE_VERSION_LINES (true/false)

Legt fest, ob --versionlines als Vorgabe aktiv ist.

DUP_PACKAGES_ONLY_OVERLAYS (true/false)

Legt fest, ob doppelte Pakete nur unter den Overlays geschehen so, d.h. ob ein Paket wird nur dann als doppelt betrachtet wird, wenn es in mindestens zwei verschiedenen Overlays vorkommt.

DUP_VERSIONS_ONLY_OVERLAYS (true/false)

Legt fest, ob doppelte Versionen nur unter den Overlays gesucht werden, d.h. ob eine Version nur dann als doppelt betrachtet wird, wenn sie mindestens zweimal in OVerlays vorkommt.

DEFAULT_IS_OR (true/false)

Wenn mehrere Suchmuster-Argumente ohne logische Verbindung (-a oder -o) auftauchen, nimmt eix implizit eine solche Verbindung an. Wenn diese Variable gesetzt ist, nimmt eix an, dass diese Verbindung -o (oder) ist, ansonsten -a (und).

OVERLAYS_LIST (all/all-if-used/all-used/all-used-renumbered/no)

Wenn man viele verschiedene Overlays hat, will man oft nicht alle Overlays am Ende aufgelistet sehen, sondern nur diejenigen, die für die Ausgabe wirklich notwendig sind. Hier kann dieses Verhalten eingestellt werden. Der Wert wird folgendermaßen interpretiert:

all-if-used/if-used/if

Listet alle Overlays, wenn zumindest einer benutzt wurde. Dies war des Standardverhalten vor eix-0.6.0.

used-renumbered/renumber/renumbered/number

Listet nur die Overlay, die tatsächlich benutzt wurden, wobei die Overlays in"Fussnotenreihenfolge" nummeriert werden (d.h. wenn nur zwei Overlays benutzt werden, werden sie mit [1] und [2] nummeriert). Der Nachteil dieses Vorgehens ist, dass Overlays für verschiedene Ausgaben verschiedene Nummern erhalten. Dennoch ist die Reihenfolge der Nummerierung konsistent.

all-used/only-used/used

Listet nur die Overlays, die tatsächlich benutzt werden, hält aber die Nummerierungsreihenfolgen über alle Aufrufe hinweg konsistent (solange die Datenbank nicht geändert wird).

no/false

Unterdrückt die Ausgabe der Overlays am Schluss.

alles andere

Gibt alle Overlays bei jeder Anfrage aus (selbst wenn kein einziger benutzt wurde).

TERM (string)

Das aktuelle Terminal. Der Wert ist typischerweise durch die Environment gesetzt.

TERM_STATUSLINE (string)

Dies ist eine Liste von Worten (durch Leerzeichen getrennt); falls eines dieser Worte mit dem Anfang von TERM übereinstimmt, wird angenommen, dass das Terminal über eine Statuszeile verfügt.

TERM_SOFTSTATUSLINE (string)

Dies ist eine Liste von Worten (durch Leerzeichen getrennt); falls eines dieser Worte mit dem Anfang von TERM übereinstimmt, und falls die Statuszeile aktiv ist, so wird ebenfalls eine Soft-Statuszeile ausgegeben; diese wird beispielsweise von screen aber nicht von tmux benutzt.

EXIT_STATUSLINE (string)

Falls dieser String nichtleer ist, wird er als Ende-Statuszeile benutzt. Ein optionales führendes Leerzeichen in diesem String wird ignoriert.

TERM_ALT1, TERM_ALT2, TERM_ALT3 (Stringliste)

Dies ist eine Liste regulärer Ausdrücke. Falls einer von ihnen auf TERM passt, wird COLORSCHEME1, COLORSCHEME2 bzw. COLORSCHEME3 statt COLORSCHEME0 benutzt, wobei die größte passende Zahl Vorrang hat.

Natürlich steht es Ihnen frei, andere Bedeutungen zuzuweisen, aber die Absicht der Vorgaben ist, dass ein Nicht-passendes Terminal 8/16 Farben hat, TERM_ALT1 die 256-farbigen Terminals spezifiziert, TERM_ALT2 die 88-farbigen Terminals, und TERM_ALT3 für den Benutzer frei bleibt (so dass damit alles andere überschrieben werden kann).

Die Vorgabeersetzung von TERM_ALT1 und TERM_ALT2 berücksichtigt TERM_ALT1_ADD bzw. TERM_ALT2_ADD durch verzögerte Ersetzung. Insbesondere können Sie eine Erweiterung der Vorgabewerte dadurch erreichen, dass Sie TERM_ALT?_ADD entsprechend definieren.

BEISPIEL 1: Falls auf allen Terminals 8/16 Farben erzwungen werden sollen, können Sie TERM_ALT3=. setzen um für alle Terminals die COLORSCHEME3-Vorgabe zu wählen (der COLORSCHEME0 ist, s. unten). Benutzer von Ethan Schoonovers solarized Farbschema sollten dies nur dann tun, wenn Sie das original 16-farbige Farbscheme von Solarized erzwingen wollen. In jedem Fall hat hat das Setzen von SOLARIZED (getrennt beschrieben) Auswirkungen.

BEISPIEL 2: Wenn Sie eix mitteilen wollen, dass TERM=rxvt ein 256-Farben Terminal ist, setzen Sie TERM_ALT1_ADD=rxvt. (Dies ist nicht mehr die Standardeinstellung, weil es rxvt-Versionen gibt, die nur 88 Farben unterstützen und TERM=rxvt setzen; daher würde es kaputte Farben geben, wenn 256 Farben angenommen würden).

SOLARIZED (true/light/dark/false)

Diese Variable wird nur bei verzögerter Ersetzung in den Vorgabewerten der COLORSCHEME?-Variablen benutzt: Wenn SOLARIZED gesetzt ist (true, light, und dark sind für eix derzeit äquivalent), wählt diese Vorgabe ein Farbschema, das annimmt, dass der Terminaloutput Ethan Schoonovers Solarized Farbscheme benutzt (helles oder dunkles Schema). Es gibt sogar ein Solarized-Farbschema für 256 Farben: Wenn das Terminal es unterstützt, werden neben den 16 Farben von Solarized noch weitere benutzt. Dies entspricht nicht ganz Ethan Schoonovers ursprünglicher Philosophie bzgl. Solarized, aber eix transportiert so viel Information über die Farben, dass diese Erweiterung angemessen erscheint. Es wird versucht, die zusätzlichen Farben möglichst zurückhaltend einzusetzen, z.B. möglichst nur für einzelne Symbole/Flags zu benutzen.

COLORSCHEME0, COLORSCHEME1, COLORSCHEME2, COLORSCHEME3 (Integer-Liste)

Welche dieser Variablen tasächlich benutzt wird hängt davon ab, welches TERM_ALT? auf TERM passt.

Der Zahlwert dieser Variablen gibt das benutzte Farbschema an; falls die Variable zwei Zahlwerte enthält (durch Leerzeichen getrennt), wird der erste bzw. zweite Wert benutzt, je nachdem ob der Dunkelmodus an oder aus ist (siehe DARK und TERM_DARK).

Der Wert 0 bedeutet, dass der erste COLORSTRING von Farbspezifikationen benutzt wird; für höhere Zahlen wird ein entsprechend späterer COLORSTRING benutzt. Falls die Zahl zu hoch ist, wird der erste COLORSTRING benutzt.

Die Vorgabewerte der COLORSCHEME?-Variablen berücksichtigen den Wert der Variablen SOLARIZED: Wenn SOLARIZED gesetzt ist, dann wird als Vorgabe ein Farbschema benutzt, das auf Ethan Schoonovers Solarized Systemfarben besiert (helles und dunkles Scheme werden beide unterstützt; in 256-farbigen Terminal werden zusätzliche Farben benutzt). Beachten Sie, dass dies nur dann eine vernünftige Ausgabe erzeugt, wenn das Terminal konfiguriert ist, die Solarized Systemfarben zu benutzen.

Die Zahlen für die Standardeinstellungen sind:

0: Dunkles Basisschema (für schwarzen Hintergrund)

1: Dunkles Schema für 256 Farben

2: Helles Basisschema (für weißen Hintergrund)

3: Helles Schema für 256 Farben

4: Solarized (light oder dark), erweitert für 256 Farben

5: Solarized original (16 Farben, light oder dark)

Die Variablen BG0, BG1, BG2, BG3 werden von den Vorgaben zur verzögerten Ersetzung berücksichtigt, um die Hintergrundfarbe der entsprechenden Schemata zu erzwingen. Die Vorgabe der BG?-Variablen ist "none": Keine Hintegrundfarbe soll erzwungen werden. Um die korrekten Hintergrundfarben zu erzwingen, setzen Sie die Variablen wie folgt:

BG0=black

BG1=black

BG2=white

BG3=white

(Je nach eix-Version sind einige davon sogar die Standardeinstellung). Dies kann jedoch unerwünschte Effekte auf transparenten Terminals haben oder falls Scrollen notwendig ist, siehe den Abschnitt FEHLER. Für diese Nebeneffekte kann es - je nach Geschmack und Terminal - nützlich/hinderlich sein, RESET_ALL_LINES=false oder RESET_ALL_LINES=true zu setzen (die Vorgabe kann von der eix-Version abhängen).

Die Standardwerte der COLORSCHEME?-Variablen sind:

COLORSCHEME0: 0 2; dies ist für Terminals mit 8/16 Farben gedacht.

COLORSCHEME1: 1 3; dies ist für 256-farbige Terminals gedacht.

COLORSCHEME2: wie COLORSCHEME0, für 88-farbige Terminals gedacht.

COLORSCHEME3: wie COLORSCHEME0, gedacht als vernünftiger Vorgabewert für Änderungen durch den Benutzer.

DARK (true/false/auto)

Der Wert dieser Variablen gibt an, ob der Dunkelmodus bei der Wahl des Farbschemas in den COLORSCHEME?-Variablen an oder aus ist. Für den Wert auto hängt das Ergebnis von einer Heuristik ab, die durch die Variablen TERM_DARK und COLORFGBG_DARK spezifiziert wird, siehe unten.

TERM_DARK (Stringliste)

Dies ist eine Liste von Paaren der Form regulärer Ausdruck 1 Dunkelmodus 1 regulärer Ausdruck 2 Dunkelmodus 2 ... wobei Dunkelmodus jeweils einer der Werte true, false, true*, false* sein muss; optional kann ein Vorgabewert für Dunkelmodus als letzter Eintrag spezifiziert werden (wenn keiner spezifiziert ist, ist true* die Vorgabe). Wenn DARK=auto ist, wird diese Liste benutzt, um den Dunkelmodus wie folgt festzulegen:

Der erste reguläre Ausdruck wird betrachtet, der auf TERM passt, und der entsprechende Dunkelmodus beschreibt, was zu tun ist (wenn kein regulärer Ausdruck passt, wird angenommen, dass der Dunkelmodus true ist): Die Werte true (oder true*) und false (oder false*) bedeuten, dass der Dunkelmodus an bzw. aus ist. Für die Werte true und false wird aber zusätzlich die Variable COLORFGBG berücksichtigt: Wenn COLORFGBG nichtleer ist, so ist der Dunkelmodus an oder aus, je nachdem ob COLORFGBG auf einen Ausdruck aus COLORFGBG_DARK passt. Beachten Sie, dass COLORFGBG eine Environment-Variable ist, die von einigen Terminals wie rxvt oder konsole gesetzt wird, um die Hintergrundfarbe zu beschreiben.

COLORFGBG_DARK (Stringliste)

Dies ist eine Liste regulärer Ausdrücke. Sie wird nur benutzt, falls DARK=auto ist, der entsprechende Dunkelmodus in DARK_MODE den Wert true oder false hat, und wenn COLORFGBG nichtleer ist. Wenn all dies zutrifft, ist der Dunkelmodus an oder aus, je nachdem of COLORFGBG auf einen der regulären Ausdrücke aus COLORFGBG_DARK passt. Beachten Sie, dass COLORFGBG eine Environment-Variable ist, die von einigen Terminals wie rxvt oder konsole gesetzt wird, um die Hintergrundfarbe zu beschreiben.

LEVENSHTEIN_DISTANCE (integer)

Legt die Vorgabe für den Levenshtein-Abstand fest.

UPDATE_VERBOSE (true/false)

Legt fest, ob eix-update -v als Vorgabe an ist (Ausgabe der effektiven Cachemethode pro Version).

EXCLUDE_OVERLAY (Stringliste)

Eine Liste von Wildcard Patterns für Overlay-Pfade, die von der Indizierung ausgeschlossen werden. Siehe die eix-update-Option --exclude-overlay.

ADD_OVERLAY (Stringliste)

Eine Liste von Overlays, die zur Indizierung hinzugefügt werden. Siehe die eix-update-Option --add-overlay.

EXPORT_PORTDIR_OVERLAY (true/false)

Falls dies gesetzt ist und Overlays hinzugefügt/entfernt wurden, wird eine entsprechend modifierte PORTDIR_OVERLAY-Variable exportiert. Dies bedeutet, dass in gewissem Sinne auch die entsprechenden eclasses dieser Overlays für die Cachemethoden eix und eix* hinzugefügt/entfernt werden.

CACHE_METHOD_PARSE (string)

Dieser String wird an alle Cachemethoden angehängt, die parse/parse*/ebuild/ebuild* benutzen. Die Vorgabe enthält #metadata-md5#metadata-flat. Außer für spezielle Situationen ist dies meist erwünscht: Es bedeutet, dass wenn aktuelle Metadaten (in einem metadata/*cache Unterverzeichnis) verfügbar sind, so werden diese anstelle des Parsens/Ausführens des ebuilds benutzt.

Letzteres ist prinzipiell nicht verlässlich (Parsen) oder ziemlich langsam (Ausführen), d.h. die Metadaten (falls vorhanden und aktuell) sind immer vorzuziehen. Näheres dazu findet sich im Abschnitt BESCHLEUNIGUNG.

PORTDIR_CACHE_METHOD, OVERLAY_CACHE_METHOD (string)

Legt den Cachetyp für Portage und Overlays fest. Die Vorgabe für PORTDIR_CACHE_METHOD ist metadata-md5-or-flat, die für OVERLAY_CACHE_METHOD ist parse|ebuild*.

Aus Geschwindigkeitsgründen sind auch für Overlays grundsätzlich Metadaten vorzuziehen. Näheres dazu findet sich im Abschnitt BESCHLEUNIGUNG.

Sicherheitswarnung: Falls die .ebuilds der Overlays nicht vollständig vertrauenswürdig sind, sollte man OVERLAY_CACHE_METHOD=parse benutzen.

Man kann auch temporär OVERLAY_CACHE_METHOD=eix*::~ setzen: Wie später erklärt, wird eix dann als Vorgabe die Overlay-Daten aus der vorherigen eix Datenbank nehmen.

Die möglichen Cachemethoden werden weiter unten beschrieben. Es ist möglich, für bestimmte Overlays andere Cachemethoden zu wählen. Dies kann über die folgenden Variablen geschehen:

CACHE_METHOD, OVERRIDE_CACHE_METHOD (Stringliste)

Diese Variablen sind Stringlisten der Gestalt "Overlay Methode Overlay Methode ...". Die Cachmethode eines jeden Overlay wird auf die darauffolgende Methode gesetzt; dies überschreibt also die Vorgabe von OVERLAY_CACHE_METHOD, (oder von PORTDIR_CACHE_METHOD falls Overlay das PORTDIR-Verzeichnis ist). Overlay wird als ein Wildcard-Muster interpretiert, das auf den Pfad (mit aufgelösten symbolischen Links) des Overlays passen sollte. (Es ist nicht möglich, hier den Repositorynamen anzugeben - es muss der aufgelöste Pfad benutzt werden). Spätere Einträge überschreiben frühere: Der letzte passende Eintrag gewinnt.

Der Unterschied zwischen CACHE_METHOD und OVERRIDE_CACHE_METHOD besteht darin, dass das erste sofort angewandt wird, während das letzte auch benutzt werden kann, um Änderungen zu überschreiben/erweitern, die implizit gemacht werden, wenn KEEP_VIRTUALS gesetzt ist (siehe unten).

Die Standarddefinitionen von CACHE_METHOD und OVERRIDE_CACHE_METHOD enthalten %{ADD_CACHE_METHOD} bzw. %{ADD_OVERRIDE_CACHE_METHOD}. Durch verspätete Ersetzung, die in einem anderen Abschnitt erklärt wird, bewirkt dies, dass die Variables ADD_CACHE_METHOD bzw. ADD_OVERRIDE_CACHE_METHOD ebenfalls benutzt werden können, um die Cachemethoden lokal zu überschreiben. Falls Sie CACHE_METHOD oder OVERRIDE_CACHE_METHOD in /etc/eixrc verändern, ist die Empfehlung zusätzlich " %{ADD_CACHE_METHOD}" bzw. " %{ADD_OVERRIDE_CACHE_METHOD}" (beachte das Leerzeichen vor %) an das Ende der neuen Definitionen anzufügen, so dass diese Variablen nach wie vor ein lokales Überschreiben erlauben.

Die folgenden Cachemethoden werden unterstützt:

metadata-flat oder metadata-flat:PFAD

Benutzt den Metadatencache innerhalb des Portagebaums ($PORTDIR/metadata/cache).

Falls PFAD angegeben ist, überschreibt dies den obigen Pfad; in diesem Fall muss der volle Pfad angegeben werden (d.h. es wird kein Präfix automatisch vorgestellt). Die Angabe von PFAD kann für Paketmanager nötig sein, die die Metadaten in einem anderen Verzeichnis generieren.

metadata-md5 oder metadata-md5:PFAD

Dies ähnlich wie metadata-flat mit dem Unterschied, dass die Dateien aus ($PORTDIR/metadata/md5-cache) benutzt werden, die eine MD5-Prüfsumme statt des Zeitstempels zur Prüfung auf Aktualität erlauben. Dies sollte die bevorzugt Methode für Overlays sein, wenn es vom Overlay unterstützt wird, d.h. wenn die metadata/layout.conf-Datei die Zeile cache-format=md5-dict enthält. (Beachte, dass nur Portage die Datei metadata/layout.conf liest; eix tut dies nicht).

metadata-assign oder metadata-assign:PFAD

Dies ist ähnlich zu metadata-flat mit dem Unterschied, dass die Dateien im Metadatencache im "assignment format" (TYP=Wert) erwartet werden, was für einige alt-gentoo-Bäume der Fall ist.

metadata-md5-or-flat, metadata-md5-or-flat:PFAD

Dies ist ähnlich zu metadata-flat mit dem Unterschied, das für jede Kategorie zunächst ein entsprechendes Verzeichnis in $PORTDIR/metadata/md5-cache gesucht wird. Falls der PFAD angegeben ist, ist diese Methode äquivalent zu metadata-md5:PFAD.

metadata-md5-or-assign, metadata-md5-or-assign:PFAD

Dies ist ähnlich zu metadata-assign mit dem Unterschied, das für jede Kategorie zunächst ein entsprechendes Verzeichnis in $PORTDIR/metadata/md5-cache gesucht wird. Falls der PFAD angegeben ist, ist diese Methode äquivalent zu metadata-md5:PFAD.

sqlite

Dies ist eine extrem schnelle Cachemethode, falls Portage mit dem sqlite-Backend benutzt wird, siehe http://wikigentoo.ksiezyc.pl/TIP_speed_up_portage_with_sqlite.htm or https://wiki.gentoo.org/wiki//etc/portage/modules (ältere Links zu diesem Thema waren http://gentoo-wiki.com/TIP_speed_up_portage_with_sqlite oder http://gentoo-wiki.info/TIP_speed_up_portage_with_sqlite oder http://en.gentoo-wiki.com/wiki/Portage_SQLite_Cache obwohl anscheinend keiner davon mehr erreichbar ist).

Beachten Sie, dass im Gegensatz zur Vorgabe-Cachemethode metadata zunächst emerge --metadata ausgeführt werden muss, bevor eix-update diese Methode benutzen kann.

Da für diese Methode sqlite installiert sein muss, ist diese Methode möglicherweise nicht in das eix-update-Programm einkompiliert. Dies ist nur der Fall, wenn eix mit dem entsprechenden USE-flag (oder manuell mit ./configure --with-sqlite vor der Kompilation) gebaut wurde.

Wie für andere Cachemethoden auch werden nur diejenigen Kategorien berücksichtigt, die durch profile/category (im Hauptbaum oder einem Overlay) festgelegt werden. Falls dies unerwünscht ist, kann man sqlite* benutzen (s. unten).

sqlite*

Dies ist analog zur Cachemethode sqlite mit dem Unterschied, dass alle Kategorien aus der Date hinzugefügt werden, selbst diejenigen, die nicht in einer profile/categories-Datei aufgelistet wurden.

flat oder flat:PFAD

Die ist ähnlich zu metadata-flat mit dem Unterschied, dass die Metadaten im Verzeichnis PFAD$PORTAGE_OR_OVERLAY_DIR erwartet werden. Falls PFAD weggelassen wird, ist seine Vorgabe /var/cache/edb/dep.

Diese Methode kann mit <portage-2.1 und dessen Standard-Backend benutzt werden.

assign oder assign:PFAD

Dies ist analog zu flat mit dem Unterchied, dass die Dateien im "assignment format" (TYP=Wert) erwartet werden. Dies ist bei portage-2.1 mit dem Standard-Backend der Fall.

Wenn >=portage-2.1 mit dem Standard-Backend benutzt wird, kann dies die Cachemethode der Wahl sein, wenn man für eix-update keinen Zugang zum Portagebaum hat. Beachten Sie, dass im Gegensatz zur Vorgabe-Methode metadata-* zunächst emerge --metadata ausgeführt werden muss, bevor man diese Methode mit eix-update benutzen kann. In diesem Fall wird man vermutlich eine entsprechende Option für eix-sync angeben.

repo-flat oder repo-flat:PFAD oder repo-assign oder repo-assign:PFAD

Dies ist analog zu flat/assign mit dem Unterschied, dass die Metadaten im Verzeichnis PFAD/$repo_name erwartet werden. Falls $repo_name leer ist, wird der Name x-XXX angenommen, wobei XXX die letzte nichtleere Pfadkomponente des Portage/Overlay-Verzeichnisses ist. Dies entspricht dem Namensschame aus paludis. Falls dies für einige Overlays den falschen Pfad liefert, lässt sich dies immer noch manuell überschreiben, z.B. mit OVERRIDE_CACHE_METHOD='bad_overlay metadata-assign:korrekter_pfad'.

parse[#Metadatenmethode]...

Holt die Informationen aus den ebuilds, die mit gewissen Heuristiken geparsed werden. Dadurch hat diese Methode keine Sicherheitsrisiken, aber möglicherweise andere Probleme. Falls Beispielsweise Variablen nur in eclass-Dateien gesetzt werden, werden sie durch diese Methode nicht erkann. Beispiele für Probleme mit dieser Methode sind fehlende Slot-Informationen für typische Ebuilds aus kde-base oder unsinnige Versionsnummer für gcc cross-compiler. Diese Methode ist die Cachemethode none älterer eix-Versionen (vor 0.11.1).

Es ist optional möglich, einen oder mehrere Strings der Gestalt #Metadatenmethode anzuhängen, wobei Metadatenmethode irgendeine der obigen Cachemethoden ist (mit Ausnahme von sqlite). In diesem Fall, werden die Metadatenmethoden anstelle des Ebuilds benutzt, falls sie aktuelle Informationen liefern. (die erste passende Metadatenmethode gewinnt).

Dies ist normalerweise das Gewünschte, vor allem für Overlays, da Metadaten verlässlicher sind als die Ergebnisse der Cachemethode parse. Natürlich ist das nur dann nützlich, wenn der Overlay foo Metadaten enthält, die vom Overlay-Maintainer regelmäßig mit

egencache --repo=foo --update

auf den neuesten Stand gebracht werden. (Ob dies für layman-Overlays geschieht, hängt vom jeweiligen Overlay-Maintainer ab; für lokale Overlays kann man natürlich das obige Kommando manuell ausführen).

Da dies normalerweise das Gewünschte ist, wird der String aus CACHE_METHOD_PARSE als Vorgabe an die Cachemethode parse angehängt.

Falls man natürlich im voraus weiß, dass die Metadaten des Overlays aktuell sind, ist es (etwas) shcneller, direkt die entsprechende Metadatenmethode (meist metadata-flat) zu benutzen. Letztere ist sinnvoll, falls beispielsweise egencache von einem Script ausgeührt wird, das zum Syncen von Overlays benutzt wird (etwa von eix-sync).

parse*[#Metadatenmethode]...

Dies ist i.W. dasselbe wie die Cachemethode parse mit dem Unterschied, dass die Variablen in Variablendefinitionen nicht expandiert werden. Dies ist die Cachemethode none* älterer eix-versionen (vor 0.11.1) und die Cachemethode none sehr alter eix-Versionen (vor 0.7.1)

ebuild[#Metadatenmethode]...

Falls kein Portage-Cache verfügbar ist (etwa für Overlays), ist dies die kompatibelste aber auch langsamste Methode. Die Information wird über "/usr/bin/ebuild ... depend" aus dem ebuild gewonnen. Da dabei die ebuilds von bash ausgeführt werden, kann dies ein Sicherheitsrisiko sein, falls man den ".ebuild"-Skripten oder den Environmentvariablen nicht vertrauen kann. Die Environment wird vor dem Ausführen bewusst nicht gelöscht, so dass weitere Variablen an das Ebuild übergeben werden können. Dies kann jedoch auch zu unerwartetem Verhalten oder gar zu einem Sicherheitsrisiko führen, da Bash-Skripte durch getürkte Environments oft irregeleitet werden können. Um solche Probleme zu vermeiden, kann man etwa env -i eix-update benutzen.

Benutzen Sie diese Methode nicht, wenn Sie nicht allen .ebuilds vertrauen, auf die diese Methode angewendet werden soll!

Die optionalen Anhänge #Metadatenmethode wurden schon bei der Cachemethode parse beschrieben. Beachten Sie, dass wenn die entsprechenden Metadaten vorhanden sind, dies wesentlich schneller ist, als das ebuild auszuführen.

ebuild*[#Metadatenmethode]...

Dies ist eine etwas schnellere und dafür etwas weniger kompatible Variante von ebuild: Die Information wird über das undokumentierte Programm "/usr/lib/portage/ebuild.sh" gewonnen. Statt also wie bei der Cachemethode ebuild ein Python-Programm für jedes ".ebuild" auszuführen, wird "nur" ein längliches Shellskript und das ebuild selbst ausgeführt (folglich ist auch diese Methode unsicher, falls man nicht allen ".ebuild"-Skripten vertrauen kann). Die meisten Environmentvariablen außer Portage-spezifischen Variablen und PATH werden gelöscht; PORTAGE_ROOTPATH wird exportiert; einige .ebuild-spezifische Variables wie $P werden gesetzt, wenn das Ebuild ausgeführt wird. Diese Methode ist nicht ganz so kompatibel wie ebuild, und es kann von der Portage-Version abhängen, ob sie überhaupt möglich ist. Aber sie ist dennoch deutlich schneller als ebuild, und stabil genug um beispielsweise typische Ebuilds aus kde-base korrekt zu handhaben.

Benutzen Sie diese Methode nicht, wenn Sie nicht allen .ebuilds vertrauen, auf die diese Methode angewendet werden soll!

parse|ebuild, parse*|ebuild, parse|ebuild*, parse*|ebuild* [#Metadatenmethode]...

Dies ist eine Mischung aus parse/parse* und ebuild/ebuild*: Jedes Ebuild wird zunächst mit der Methode parse/parse* untersucht. Wenn im Ergebnis offensichtlich Informationen fehlen oder merkwürdig erscheinen, wird das Ebuild der Cachemethode ebuild/ebuild* unterzogen. Als Faustregel ist diese Methode wesentlich schneller als ebuild/ebuild* aber immer noch wesentlich langsamer als parse/parse*. Natürlich hat sie die selben sicherheitsprobleme wie ebuild/ebuild*.

Benutzen Sie diese Methode nicht, wenn Sie nicht allen .ebuilds vertrauen, auf die diese Methode angewendet werden soll!

eix oder eix:DATEI oder eix:DATEI:Overlay

Benutzt die Cachedatei DATEI, die durch einen frühren Aufruf von eix-update erzeugt wurde. Falls DATEI leer ist oder weggelassen wird, ist die Vorgabe /var/cache/eix/portage.eix.

Wie für andere Cachemethoden auch werden nur diejenigen Kategorien berücksichtigt, die durch profile/category (im Hauptbaum oder einem Overlay) festgelegt werden. Falls dies unerwünscht ist, kann man eix* benutzen (s. unten).

Falls Overlay nicht angegeben wurde oder leer ist, wird nur der "Hauptbaum" aus DATEI gelesen - Overlays innerhalb DATEI werden ignoriert. Andernfalls wird nur der zum Overlay zugehörige Teil aus DATEI gelesen. Hierbei bedeutet "zugehöriger Teil" den ersten Overlay aus DATEI, der auf das Wildcard-Muster Overlay passt. "Passen" wiederum bedeutet, dass zunächst das Label getestet wird, dann der Pfad und schließlich die Nummer des Overlays innerhalb DATEI. Beachte, dass Overlay i.a. nicht in Verbindung mit aktuellen Overlaynamen oder -nummern stehen muss: Nur die in DATEI gespeicherten Namen/Nummern sind hier entscheidend.

Es gibt zwei Ausnahmewerte für Overlay, die nach anderen Regeln behandelt werden:

Falls Overlay den speziellen Wert "~" hat, so wird der Names des aktuellen Overlaylabels implizit als Overlay-Argument benutzt; falls das aktuelle Overlaylabel leer ist oder nicht passt, wird statt dessen der aktuelle Overlaypfad benutzt.

Falls Overlay den speziellen Wert "*" hat, so werden all Overlays aus DATEI gelesen. Beachten Sie, dass dies normalerweise nicht das Gewünschte ist, weil es bedeutet, dass falls DATEI ursprünglich mehrere Overlays enthielt, wird diese Overlay-Struktur "eingeflacht".

eix* oder eix*:DATEI oder eix*:DATEI:Overlay

Dies ist analog zur Cachemethode eix mit dem Unterschied, dass alle Kategorien aus DATEI hinzugefügt werden, auch jene, die nicht in einer profile/categories-Datei gelistet wurden.

Diese cachemethode ist nützlich, falls DATEI Informationen über ein Overlay-Verzeichnis enthält, dessen entsprechendes profile/categories-Datei auf dem lokalen Rechner unbekannt oder nicht notwendigerweise aktuell ist.

Dies wird für eix-remote benutzt.

Beachten Sie insbesondere, dass mit PORTDIR_CACHE_METHOD=eix*::~ die Overlaydaten als Vorgabe einfach von der vorherigen eix-Cachedatei "kopiert" werden.

KEEP_VIRTUALS (true/false)

Falls diese Variable gesetzt ist, wird eix-update alle virtuellen Overlays aus dem vorhergehenden Cachefile (falls es ein solches gibt) übernehmen.

Dies hat den selben Effekt als wenn man für jeden virtuellen Overlay der alten Datenbank den Eintrag "Overlayname" zu ADD_OVERLAY hinzufügt und einen entsprechenden Eintrag "Overlay eix*::Overlay" zu CACHE_METHOD. Dies bedeutet, dass diese Option ggf. Angaben aus CACHE_METHOD überschreibt. Die Änderungen können allerdings wieder durch OVERRIDE_CACHE_METHOD überschrieben werden.

REPO_NAMES

Diese Variable ist eine Stringliste der Gastalt "Verzeichnismuster Overlaylabel Verzeichnismuster Overlaylabel ...". Bei der Erzeugung einer neuen Datenbank erhält der Overlay, der auf Verzeichnismuster passt das Label Overlay-label, unabhängig vom Inhalt seiner profiles/repo_name Datei. Diese Variable kann auch virtuellen Overlays, die naturgemäß keine solche Datei haben können, Labelnamen zuordnen. Insbesondere kann diese Variable auch Overlaylabel überschreiben, die durch KEEP_VIRTUALS gesetzt werden. Spätere Einträge überschreiben frühere: Der letzte passende Eintrag gewinnt.

LOCAL_PORTAGE_CONFIG (true/false)

Falls nicht gesetzt, werden /etc/portage und ACCEPT_KEYWORDS (aus make.conf bzw. der Environment) ignoriert. Seit eix-0.7.9 wird empfohlen, den Wert dieser Variable auf dem Vorgabewert "true" zu belassen, weil durch das Setzen auf "false" nur Informationen vor dem Benutzer versteckt werden.

ALWAYS_ACCEPT_KEYWORDS (true/false)

Entscheidet, ob ACCEPT_KEYWORDS selbst ohne LOCAL_PORTAGE_CONFIG benutzt wird, etwa um die "Standard"-Stabilität zu berechnen.

UPGRADE_LOCAL_MODE (+ oder local/- oder non-local/etwas anderes)

Falls diese Variable + / - ist, wird sich die --upgrade-Option von eix so verhalten, als wenn LOCAL_PORTAGE_CONFIG auf true / false gesetzt wäre.

RECOMMEND_LOCAL_MODE (+ oder local/- oder non-local/etwas anderes)

Falls diese Variable + / - ist, werden sich upgrade/downgrade-Empfehlungen sowie in eix-diff die Tests auf Versionsänderungen so verhalten, als wenn LOCAL_PORTAGE_CONFIG auf true / false gesetzt wäre.

UPGRADE_TO_HIGHEST_SLOT (true/false)

Entscheidet, ob Upgrade-Tests ein positives Ergebnis liefern, falls für ein installiertes Paket nicht der Slot mit der höchsten stabilen Version installiert ist. Ausnahmen dieser allgemeinen Politik können in /etc/portage/package.slot_upgrade_forbid bzw. /etc/portage/package.slot_upgrade_allow angegeben werden.

RECURSIVE_SETS (true/false)

Entscheidet of Sets und Pakete eines inkludierten Sets als Teil des Eltern-Sets verstanden werden sollen.

XML_KEYWORDS(full/effective/both/true/full*/effective*/none/false)

Entscheidet bei --xml, ob die vollen/effektiven (oder beide) Typen von KEYWORDS für jede Version ausgegeben werden. Hier heißt "voll" der KEYWORDS-String des Ebuild und "effectiv" seine eventuelle Modifikation durch das Profil. Die Werte full*/effective* sind ähnlich full/effective, aber beide Typen werden ausgegeben, wenn sich ihre Werte unterscheiden. true/false ist gleichbedeutend mit full*/none.

XML_OVERLAY (true/false)

Entscheidet bei --xml, ob der Overlay (d.h. sein Pfad) für jede Version ausgegeben werden soll. Für Versionen aus Overlays ohne Label (Repositorynamen) hat dies keinen Einfluss: Für solche Version wird grundsätzlich der Overlay ausgegeben.

SORT_INST_USE_ALPHA (true/false)

Bei true werden die USE-Flags installierter Pakete in alphabetischer Reihenfolge ausgegeben. Andernsfalls werden (in alphabetischer Reihenfolge) zunächst diejenigen ausgegeben, die beim Emerge des Pakets gesetzt waren und dann die restlichen (ebenfalls in alphabetischer Reihenfolge).

CHECK_INSTALLED_OVERLAYS (true/false/repository)

Bei true wird grundsätzlich überprüft, von welchem Overlay ein Paket installiert wurde. Bei false wird das nur für diejenigen Pakete überprüft, die in mindestens zwei Bäumen verfügbare Versionen haben, d.h. nur für Pakete, bei denen es anhand der Datenbank vernünftig erscheint, dass es von einem anderen Overlay installiert sein könnte. Diese Information könnte natürlich falsch sein, falls das Paket nach der Installation aus dem Overlay entfernt wurde, oder falls sich der gesamte Overlay nicht mehr in der Datenbank befindet.

Der spezielle Wert repository ist ein vernünftiger Kompromiss: Falls Repository-Daten beim Emerge gespeichert wurden (was nur bei aktuelleren Portage-Verseionen der Fall ist; mit eix-installed [no-]repository lässt sich überprüfen, für welche Versionen das (nicht) der Fall ist), dann werden diese Repository-Daten grundsätzlich benutzt. Nur wenn sie fehlen, ist das Verhalten für die entsprechende Version wie im Falle CHECK_INSTALLED_OVERLAYS=false.

Vor allem im Zusammenhang mit der Option -T (falls NONEXISTENT_IF_OTHER_OVERLAY gesetzt ist) und mit der Option -J ist der Geschwindigkeitszuwachs enorm, wenn diese Variable auf false oder repository gesetzt ist, aber man sollte sich bewussst sin, dass die erhaltene Information über installierte Overlays dann nicht vollkommen verlässlich ist (für mit älteren Portage-Versionen installierte Pakete). Insbesondere wird die Option -T nicht feststellen, falls eine installierte Version eines Pakets tatsächlich aus einem redundanten Overlay stammt, falls in der aktuellen Datenbank alle Version des Paket von einem einzigen (anderen) Repository kommen.

PRINT_COUNT_ALWAYS (true/false/never)

Bei true wird stets die Trefferzahl in der letzten Zeile ausgegeben, selbst dann, wenn diese Zahl 0 oder 1 sein sollte. Bei PRINT_COUNT_ALWAYS=never wird diese letzte Zeile grundsätzlich unterdrückt. Beides ist im Normalfall nicht nützlich, aber es kann für einfache Skripte bequem sein, die die Ausgabe von eix parsen.

COUNT_ONLY_PRINTED (true/false)

Bei false wird nur die Trefferzahl der Pakete berücksichtigt, unabhängig davon, ob diese Treffer zu irgendeiner Ausgabe geführt haben. Dies kann für gewisse Skripte nützlich sein bei denen man nur an der Trefferzahl interessiert ist, und für die dann zur Beschleunigung beispielsweise FORMAT='' benutzt werden kann.

DEFAULT_MATCH_FIELD (Stringliste) Dies ist eine Stringliste der Gestalt regulärer_Ausdruck[\n\r\t ]Operandenfeld, die benutzt wird, um die Vorgaben für das Operandenfeld (gegen das das Suchmuster getestet wird) zu ermitteln. Das Suchmuster der Kommandozeile wird dazu gegen alle Werte aus regulärer_Ausdruck der Liste (in der Reihenfolge der Liste) getestet. Für den ersten Treffer wird das entsprechende Operandenfeld als Vorgabe benutzt. Es kann ein abschließendes Operandenfeld (ohne regulärer_Ausdruck) in der Liste angegeben werden, das als Vorgabe dient, wenn es keinen anderen Treffer gab; wenn es keinen solchen letzten Eintrag gibt, wird name angenommen. Für die Angaben von regulärer_Ausdruck kann die verspätete Ersetzung vom Typ ${\VAR} praktisch sein, da man sich so das händische Escapen spart.

Die möglichen Werte für Operandenfeld sind: name, category, category/name (oder category-name), description, license, homepage, set, eapi, installed-eapi, slot, installed-slot, use (oder iuse), with-use (oder installed-with-use), without-use (oder installed-without-use), src-uri (oder srcuri), deps, depend, rdepend, pdepend, bdepend und error. Sie entsprechen den analogen Kommandozeilenoptionen für die Operandenwahl. Der spezielle Wert error bedeutet, dass eix mit der Fehlermeldung abbricht, dass das Operandenfeld nicht automatisch erkannt werden kann und explizit angegeben werden muss.

Zum Testen von Skripten empfiehlt es sich, DEFAULT_MATCH_FIELD=error zu setzen, so dass sich Skripte nicht auf spezielle Vorgaben von DEEFAULT_MATCH_FIELD verlassen: Diese Vorgabe hat sich in der Geschichte von eix bereits mehrfach geändert und wird es vermutlich irgendwann wieder tun.

DEFAULT_MATCH_ALGORITHM (Stringliste)

Dies ist eine Stringliste der Gestalt (Operandenfeld_Spezifikation)regulärer_Ausdruck[\n\r\t ]Matchalgorithmus, die benutzt wird, um die Vorgabe für den Matchalgorithmus (für den das Suchmuster gedacht ist) zu ermitteln. Dies ist analog wie bei DEFAULT_MATCH_FIELD, haupstächlichr mit dem Unterschied, dass natürlich Matchalgorithmus den Vorgabe-Matchalgorithmus angibt.

Die möglichen Werte für Matchalgorithmus sind: regex, pattern, substring, begin, end, exact, fuzzy. Sie entsprechen den analogen Kommandozeilenoptionen für die Wahl des Matchalgorithmus. Der spezielle Wert error bedeutet, dass eix mit der Fehlermeldung abbricht, dass der Matchalgorithmus nicht automatisch erkannt werden kann und explizit angegeben werden muss. Falls keine andere Vorgabe für den Matchalgorithmus spezifiziert wird, wird regex benutzt.

In jedem String kann einer der beiden Teile (Operandenfeld_Spezifikation) und regulärer_Ausdruck weggelassen werden. Wird keiner weggelassen, müssen sie beide gleichzeitig passen, damit der Algorithmus selektiert wird. Die Operandenfeld_Spezifikation bezieht sich auf die effektiv selektierten Operandenfeld-Werte gemäß der folgenden Regeln.

Operandenfeld_Spezifikation ist eine Verkettung von Worten der Gestalt |Operandenfeld, &Operandenfeld und !Operandenfeld,, wobei für Operandenfeld die selben Werte möglich sind wie in DEFAULT_MATCH_FIELD (mit Ausnahme von error). Die Reihenfolge dieser Worte spielt keine Rolle.

eix kombiniert alle Operandenfeld-Werte, die mit dem selben Zeichen beginnen (|, & oder !) und gewinnt dadurch 3 (möglicherweise leere) Familien von Operandenfeldern. Die Operandenfeld_Spezifikation passt, wenn die folgenden Bedingungen alle erfüllt sind:

1. Wenn die erste Familie (|) nicht leer ist, so ist mindestens ein Operandenfeld dieser Familie effektiv selektiert (man denke an ein logisches "oder").

2. Mindestens all Operandenfelder der zweiten Familie (&) sind effektiv selektiert (man denke an ein logisches "und").

3. Wenn die dritte Familie (!) nicht leer ist, so sind höchststens Operandenfelder dieser Familie selektiert (man denke an ein logisches "nicht (... oder ... oder ...)").

Um beispielsweise anzugeben, dass genau alle der Felder depend, rdepend, pdepend, bdepend selektiert sind (also --deps) und kein weiteres, kann man einen der Spezifikationen

(&deps!deps)

(&depend&rdepend&pdepend&bdepend!depend!rdepend!pdepend!bdepend)

benutzen. Will man andererseits spezifieren, dass mindestens eines von depend, rdepend, pdepend, bdepend selektiert ist aber ansonsten nichts, kann man das wie folgt tun:

(|deps!deps)

(|depend|rdepend|pdepend|bdepend!depend!rdepend!pdepend!bdepend)

Zum Testen von Skripten empfiehlt es sich, DEFAULT_MATCH_ALGORITHM=error zu setzen, so dass sich Skripte nicht auf spezielle Vorgaben von DEEFAULT_MATCH_ALGORITHM verlassen: Diese Vorgabe hat sich in der Geschichte von eix bereits mehrfach geändert und wird es vermutlich irgendwann wieder tun.

TEST_FOR_EMPTY (true/false) Legt fest, ob leere Einträge in /etc/portage/package.* bei -t angezeigt werden.

TEST_KEYWORDS (true/false)

Legt fest, ob /etc/portage/package.{accept_,}keywords bei -t getestet wird.

TEST_MASK (true/false)

Legt fest, ob /etc/portage/package.mask bei -t getestet wird.

TEST_UNMASK (true/false)

Legt fest, ob /etc/portage/package.unmask bei -t getestet wird.

TEST_USE (true/false)

Legt fest, ob /etc/portage/package.use bei -t getestet wird.

TEST_ENV (true/false)

Legt fest, ob /etc/portage/package.env bei -t getestet wird.

TEST_LICENSE (true/false)

Legt fest, ob /etc/portage/package.license bei -t getestet wird.

TEST_RESTRICT (true/false)

Legt fest, ob /etc/portage/package.accept_restrict bei -t getestet wird.

TEST_CFLAGS (true/false)

Legt fest, ob /etc/portage/package.cflags bei -t getestet wird.

TEST_REMOVED (true/false)

Legt fest, ob gelöschte Pakete mit -t getestet werden.

TEST_FOR_NONEXISTENT (true/false)

Legt fest, ob nicht-existente installierte Versionen bei -T positiv sind. Die NONEXISTENT_IF-Variablen legen dabei fest, was nicht-existent bedeutet.

TEST_FOR_REDUNDANCY (true/false)

Legt fest, ob redundante Einträge in /etc/portage/package.* bei -T positiv sind. Die REDUNDANT_IF-Variablen legen dabei fest, was redundant bedeutet.

ACCEPT_KEYWORDS_AS_ARCH (full/true/false)

Bei full oder true wird ARCH durch ACCEPT_KEYWORDS modifiziert. Dadurch wird geregelt, welche Keywords als ARCH oder OTHERARCH betrachtet werden. Der Wert full beeinflusst außerdem das ursprüngliche Keywording durch ARCH.

NONEXISTENT_IF_OTHER_OVERLAY (true/false)

Legt fest, ob Versionen bei TEST_FOR_NONEXISTENT als nicht-existent betrachtet werden, wenn sie nur von einem anderen Overlay als die installierte Version kommen.

NONEXISTENT_IF_MASKED (true/false)

Legt fest, ob maskierte Versionen bei TEST_FOR_NONEXISTENT. als nicht-existent betrachtet werden.

REDUNDANT_IF_DOUBLE (string)

Dies definiert den TEST_FOR_REDUNDANCY, der positiv ausfällt, falls in /etc/portage/package.{accept_,}keywords das selbe Keyword zweimal für einige/alle (un-/installierten) Versionen gelistet wird.

string beschreibt dabei, welche Versionen getestet werden. Die folgenden Werte sind dabei zulässig:

no oder false

Teste nicht auf dies Art der Redundanz (keine der Versionen).

some

Der Test ist positiv, falls die Redundanz für irgendeine Version der Datenbank auftritt.

all

Der Test ist positiv, falls die Redundanz für alle Versionen der Datenbank auftritt.

some-installed

Der Test ist positiv, falls die Redundanz für eine installierte Version auftritt. Uninstallierte Versionen werden dabei ignoriert.

all-installed

Der Test ist positiv, falls die Redundanz für alle installierten Versionen des Pakets auftritt. Falls keine Version installiert ist, ist der Test positiv, falls die Redundanz für eine Version auftritt.

some-uninstalled

Der Test ist positiv, falls die Redundanz für eine uninstallierte Version auftritt. Installierte Versionen werden dabei ignoriert.

all-uninstalled

Der Test ist positiv, falls die Redundanz für alle uninstallierten Versionen auftritt. Falls alle Versionen installiert sind, ist der Test positiv, falls die Redundanz für eine Version auftritt.

-etwas von Obigem oder +etwas von Obigem

Der Test erfolgt nur, wenn zusätzlich keine Version (im Falle -) bzw. mindestens eine Version (im Falle +) des Pakets instaliert ist.

etwas von Obigem or etwas von Obigem

Der Test ist positiv, wenn mindestens einer der beiden Tests positiv ist. Statt "or" können auch die Zeichen "|" oder "||" benutzt werden.

REDUNDANT_IF_DOUBLE_LINE (string, siehe oben)

Dies testet, ob /etc/portage/package.{accept_,}keywords für die entsprechenden Versionen zwei Zeilen für identische Ziele enthält, d.h. so dass Portage die erste der Zeilen ignorieren würde. Beachte, dass Zeilen mit den Zielen foo/bar und =foo/bar-1 in diesem Zusammenhang von Portage (und daher auch von eix) als verschiedene Ziele betrachtet werden, selbst dann, wenn foo/bar sich auf die Version 1 bezieht. Redundanzen von letzterem Typ können implizit mit REDUNDANT_IF_DOUBLE_LINE, REDUNDANT_IF_MIXED, und REDUNDANT_IF_STRANGE gefunden werden.

REDUNDANT_IF_MIXED (string, siehe oben)

Dies testet, ob /etc/portage/package.{accept_,}keywords für die betreffenden Versionen zwei verschiedene Keywords listet, z.B. ~ARCH und **

REDUNDANT_IF_WEAKER (string, siehe oben)

Dies testet, ob /etc/portage/package.{accept_,}keywords für die entsprechenden Versionen ein Keywords enthält, das durch ein schwächeres Keyword ersetzt werden kann, etwa **, ~OTHERARCH oder OTHERARCH statt ~ARCH, oder ~OTHERARCH statt OTHERARCH.

REDUNDANT_IF_STRANGE (string, siehe oben)

Dies testet, ob /etc/portage/package.{accept_,}keywords für die entsprechenden Versionen ein merkwürdiges Keywords enthält, etwas UNKNOWNARCH (weder im .ebuild noch in ARCH gelistet) oder -OTHERARCH.

REDUNDANT_IF_NO_CHANGE (string, siehe oben)

Dies testet, ob /etc/portage/package.{accept_,}keywords Keywords enthält, die nicht den Stabilitätsstatus der entsprechenden Versionen ändern.

REDUNDANT_IF_MASK_NO_CHANGE (string, siehe oben)

Dies testet, ob /etc/portage/package.mask Einträge enthält, die nicht den Maskenstatus der entsprechenden Version ändern.

REDUNDANT_IF_UNMASK_NO_CHANGE (string, siehe oben)

Dies testet, ob /etc/portage/package.unmask Einträge enthält die nicht den Maskenstatus der entsprechenden Version ändern.

REDUNDANT_IF_DOUBLE_MASKED (string, siehe oben)

Dies testet, ob /etc/portage/package.mask zweimal auf die entsprechende Version zutrifft.

REDUNDANT_IF_DOUBLE_UNMASKED (string, siehe oben)

Dies testet, ob /etc/portage/package.unmask zweimal auf die entsprechende Version zutrifft.

REDUNDANT_IF_DOUBLE_USE (string, siehe oben)

Dies testet, ob /etc/portage/package.use zweimal auf die entsprechende Version zutrifft.

REDUNDANT_IF_DOUBLE_ENV (string, siehe oben)

Dies testet, ob /etc/portage/package.env zweimal auf die entsprechende Version zutrifft.

REDUNDANT_IF_DOUBLE_LICENSE (string, siehe oben)

Dies testet, ob /etc/portage/package.license zweimal auf die entsprechende Version zutrifft.

REDUNDANT_IF_DOUBLE_RESTRICT (string, siehe oben)

Dies testet, ob /etc/portage/package.accept_restrict zweimal auf die entsprechende Version zutrifft.

REDUNDANT_IF_DOUBLE_CFLAGS (string, siehe oben)

Dies testet, ob /etc/portage/package.cflags zweimal auf die entsprechende Version zutrifft. Beachte, dass diese Datei von Portage nicht unterstützt wird, aber sie könnte von einer lokalen /etc/portage/bashrc-Datei unterstützt werden. Dies heißt natürlich, dass die Datei /etc/portage/package.cflags kein offiziell unterstützes Format hat. eix nimmt an, dass das Format analog zu /etc/portage/package.{keywords,use} ist (d.h. ein Eintrag ist höchstens eine Zeile mit den gewünschten Paketen/Versionen zu Beginn der Zeile). Wie die anderen /etc/portage/package.*-Dateien kann /etc/portage/package.cflags auch ein Verzeichnisbaum sein. In diesem Fall werden alle nicht-versteckten Dateien/Unterverzeichnisse dieses Baums rekursiv gelesen, wobei alle symbolischen Links aufgelöst werden.

REDUNDANT_IF_IN_KEYWORDS (string, siehe oben)

Dies testet, ob /etc/portage/package.{accept_,}keywords einen nichtleeren Eintrag für die betreffende Version enthält (leere Einträge findet man mit -t). Natürlich wird man nicht alle Treffer als Redundanz betrachten (obwohl man diese Option missbrauchen könnte, um alle Treffer zu listen). Aber man könnte passende aber nicht-installierte Pakete als redundant betrachten. Daher wird man diese Werte typischerweise auf den Wert -some oder den äquivalenten Wert -some-uninstalled setzen (oder auf false, wenn man der Meinung ist, dass Einträge für uninstallierte Pakete "normal" und nicht redundant sind).

REDUNDANT_IF_IN_MASK (string, siehe oben)

Dies ist analog zu REDUNDANT_IF_IN_KEYWORDS, aber für /etc/portage/package.mask.

REDUNDANT_IF_IN_UNMASK (string, siehe oben)

Dies ist analog zu REDUNDANT_IF_IN_KEYWORDS, aber für /etc/portage/package.unmask.

REDUNDANT_IF_IN_USE (string, siehe oben)

Dies ist analog zu REDUNDANT_IF_IN_KEYWORDS, aber für /etc/portage/package.use.

REDUNDANT_IF_IN_ENV (string, siehe oben)

Dies ist analog zu REDUNDANT_IF_IN_KEYWORDS, aber für /etc/portage/package.env.

REDUNDANT_IF_IN_LICENSE (string, siehe oben)

Dies ist analog zu REDUNDANT_IF_IN_KEYWORDS, aber für /etc/portage/package.license.

REDUNDANT_IF_IN_RESTRICT (string, siehe oben)

Dies ist analog zu REDUNDANT_IF_IN_KEYWORDS, aber für /etc/portage/package.accept_restrict.

REDUNDANT_IF_IN_CFLAGS (string, siehe oben)

Dies ist analog zu REDUNDANT_IF_IN_KEYWORDS, aber für /etc/portage/package.cflags. Siehe die obigen Bemerkungen zu dieser Datei.

SLOT_UPGRADE_FORBID (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.slot_upgrade_forbid dienen.

SLOT_UPGRADE_ALLOW (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.slot_upgrade_allow dienen.

KEYWORDS_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.{accept_,}keywords.nonexistent dienen.

MASK_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.mask.nonexistent dienen.

UNMASK_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.unmask.nonexistent dienen.

USE_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.use.nonexistent dienen.

ENV_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.env.nonexistent dienen.

LICENSE_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.license.nonexistent dienen.

RESTRICT_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.accept_restrict.nonexistent dienen.

CFLAGS_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.cflags.nonexistent dienen.

INSTALLED_NONEXISTENT (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.installed.nonexistent dienen.

PACKAGE_NOWARN (Stringliste)

Dies ist eine Liste aller Datei/Verzeichnisnamen, die als /etc/portage/package.nowarn dienen.

 

/etc/portage/sets.eix

Dies Verzeichnis ist ähnlich wie /etc/portage/sets (siehe die Portage Manpage). Da Portage einige Möglichkeiten hat, Sets zu definieren, die für eix nicht verfügbar sind, kann man dieses Verzeichnis benutzen, um (statische) Sets zu speichern, von denen man will, dass sie eix bekannt sind (so dass beispielsweise Sets-Einträge in /etc/portage/package.{accept_,}keywords entsprechend behandelt werden können).

 

/etc/portage/package.slot_upgrade_forbid

 

/etc/portage/package.slot_upgrade_allow

Ähnlich wie alle anderen /etc/portage/package.* kann dies eine Datei oder ein Verzeichnis sein. Die Einträge dieser Datei haben die Gestalt "category/name" (getrennt durch Zeilenvorschub). Die entsprechenden Pakete werden als Ausnahmen für UPGRADE_TO_HIGHEST_SLOT behandelt.

 

/etc/portage/package.{accept_,}keywords.nonexistent

 

/etc/portage/package.keywords.nonexistent

 

/etc/portage/package.mask.nonexistent

 

/etc/portage/package.unmask.nonexistent

 

/etc/portage/package.use.nonexistent

 

/etc/portage/package.env.nonexistent

 

/etc/portage/package.license.nonexistent

 

/etc/portage/package.accept_restrict.nonexistent

 

/etc/portage/package.cflags.nonexistent

Ähnlich wie /etc/portage/package.* kann dies eine Datei oder ein Verzeichnis sein. Falls ein Eintrag (durch Leerzeichen oder Zeilenvorschub getrennt) auf das erste Wort oder eine Zeile der entsprechenden /etc/portage/package.* Datei passt, wird diese Zeile von Tests mit -t ausgenommen (für Namen, die nicht in der Datenbank sind). Dies kann benutzt werden, um bestimmte Warnungen von -t auszuschalten.

 

/etc/portage/package.installed.nonexistent

Dies ist ähnlich zu den anderen /etc/portage/package.*.nonexistent Dateien/Verzeichnissen mit dem Unterschied, dass es Meldungen von -t über installierte Pakete ausschaltet, die aus der Datenbank entfernt wurden. Die Einträge dieser Datei haben die Gestalt "category/name", aber man kann auch auf den "category/"-Teil verzichten (obwohl dies nicht empfehlenswert ist).

 

/etc/portage/package.nowarn

Ähnlich wie /etc/portage/package.* kann dies eine Datei oder ein Verzeichnis sein. Mit dieser Datei/Verzeichnis können Test mit -T für bestimmte Pakete unterdrückt werden. Das Format dieser Datei ist ähnlich zu /etc/portage/package.use mit dem Unterschied, dass man Tests an- oder abschalten kann. Es werden alle Zeilen aktiv, für die mindestens eine passende Version verfügbar ist. Beispielsweise bewirken die Zeilen

sys-kernel/*-sources no_change weaker

>sys-kernel/hardened-sources-2.6.40 -weaker

in dieser Datei, dass -T die Pakete sys-kernel/*-sources nicht meldet, wenn der einzige Grund dafür wäre, dass REDUNDANT_IF_NO_CHANGE oder REDUNDANT_IF_WEAKER gesetzt ist. Eine Ausnahme dieser Regel gibt es nur für REDUNDANT_IF_WEAKER und hardened-sources, falls letzteres wenigestens in der Version 2.6.40 verfügbar ist. Die Reihenfolge in der Datei spielt keine Rolle: Ein "-" hat stets Vorrang, wenn es irgendwo auftaucht.

Man kann Pakete in dieser Datei wiederholt listen; die gelisteten Tests wirken für das entsprechende Paket kumulativ.

Verfübare Tests sind: in_keywords, no_change, double, mixed, weaker, double_line, in_mask, mask_no_change, double_masked, in_unmask, unmask_no_change, double_unmasked, in_use, double_use, in_env, double_env, in_license, double_license, in_restrict, double_restrict, in_cflags, double_cflags. Die Bedeutung entspricht der zugehörigen REDUNDNANT_IF_*-Variablen.

Zusätzlich gibt es die Tests nonexistent, masked, other_overlay, deren Bedeutung den zugehörigen Variablen TEST_FOR_NONEXISTENT, NONEXISTENT_IF_MASKED, NONEXISTENT_IF_OTHER_OVERLAY entspricht.

 

/var/cache/eix/portage.eix

Dies ist die Binärdatenbank für eix. Der Pfad kann mit der Variablen EIX_CACHEFILE geändert werden (deren Vorgabe EPREFIX über verzögerte Ersetzung berücksichtigt).

 

/var/cache/eix/previous.eix

Dies ist die vorhergehende Version von /var/cache/eix/portage.eix, die von eix-diff und eix-sync benutzt wird. Der Pfad kann mit der Variablen EIX_PREVIOUS geändert werden (deren Vorgabe EPREFIX über verzögerte Ersetzung berücksichtigt).

 

/var/cache/eix/remote.tar.bz2 und /var/cache/eix/remote2.tar.bz2

Dies ist eine lokale Kopie des Remote-Archivs, das von eix-remote benutzt wird. Der Pfad kann mit der Variablen EIX_REMOTEARCHIVE1 bzw. EIX_REMOTEARCHIVE2 geändert werden (deren Vorgaben EPREFIX über verzögerte Ersetzung berücksichtigen).

 

masked-packages

masked-packages ist ein Hilfsprogramm für Skripte, das die Argumente gegen eine Liste von Paketmasken testet. Die Masken werden durch die Optionen spezifiert; sie sollten im selben Format sein wie /etc/portage/package.mask Die Argumente werden in der Form Kategorie/Name-Version[:Slot][::Repo] erwartet. Als Vorgabe werden die Argumente ausgegeben, die auf eine Maske passen.

 

Beispiele:

masked-packages -q --file /etc/portage/package.accept_keywords app-portage/eix-99999999::mv

Kehrt erfolgreich zurück, falls ein Eintrag aus /etc/portage/package.accept_keywords auf die Version app-portage/eix-99999999::mv passt.

masked-packages -m '=a/b-1*:1' -m '=c/d-1' a/b-0:1 a/b-1.1:1 a/b-1.2 c/d-1:2

Gibt nur a/b-1.1:1 und c/d-1:2 aus, da bei den anderen Argumenten Version bzw. Slot nicht auf die Maske passen.

 

Optionen

-h, --help

Ausgabe eines Hilfstextes und Ende.

-q, --quiet (toggle)

Anstelle der Ausgabe der Argument wird nur anhand des Rückgabewerts gezeigt, ob ein Argument gepasst hat. Genauer ist der Rückgabewert nur dann erfolgreich, wenn mindestens ein Argument passt.

-Q, --nowarn (toggle)

Keine Ausgabe von Warnungen bzgl. falscher Syntax.

-m, --mask MASKE

Fügt MASKE der Maskenliste hinzu.

-f, --file DATEI

Fügt die Zeilen von DATEI der Maskenliste hinzu. DATEI kann auch leer sein oder - oder ein Verzeichnis: Ein leerer Filename oder - wird als Standardeingabe interpretiert, ein Verzeichnis wird rekursiv gelesen.

-F, --read-file DATEI

Fügt alle Worte aus DATEI der Liste von Argumenten hinzu. DATEI kann auch leer sein oder - oder ein Verzeichnis: Ein leerer Filename oder - wird als Standardeingabe interpretiert, ein Verzeichnis wird rekursiv gelesen.

 

versionsort

versionsort ist ein Hilfstool für Skripte, das zwei Zwecken dient: Es schneidet den Versionsstring und verschiedenen nicht-alphanumerischen Müll von seinen Argumenten ab und interpretiert diese Argumente selbst als Versionsstrings (nach einer Heuristik). Dann gibt es alle diese Versionsstrings in sortierter Reihenfolge aus, wobei die Portage-Regeln der Versionssortierung berücksichtigt werden. Bei mehr als einem Argument wird nach jeder Version (einschließlich der letzten) ein Zeilenvorschub ausgegeben. Beispiel:

versionsort '>=gcc-4.4' 4.4_alpha0 '<sys-devel/gcc-4.05' 4.5

wird folgendes ausgeben:

4.05

4.4_alpha0

4.4

4.5

Falls nur ein Argument übergeben wird, ist versionsort weniger streng bzgl. der Versionsregeln; selbst wenn der Versions-Teil nicht vollständig korrekt ist, wird in diesem Fall garantiert, dass die Ausgabe zeichengleich mit dem Versionsteil ist. Daher kann versionsort mit einem Argument benutzt werden, um in einem Shellskript den Paketnamen vom Versionsteil abzutrennen, etwa so:

split=1-font-adobe-75dpi-1.3-r1

version=`versionsort "X$split"`; name=${split%"-$version"}

Obwohl es derzeit keinen Unterschied macht, ist es zukunftssicherer (bzgl. möglicher künftiger Änderungen des Versionsformats) das Argument mit einer Nicht-Ziffer (wie X in obigem Beispiel) beginnen zu lassen, um sicherzustellen, dass versionsort tatsächlich die Version abtrennt und nicht fälschlicherweise das gesamte Argument als eine einzige Version interpretiert.

Seit eix-0.25.6 unterstützt versionsort auch einige Optionen: Mit -n, -p, -f, -v, -r bzw. -V wird nur der Name (ohne Versionsanhang), Name mit Version (ohne Revisionsanhang), Name mit Version und Revisionsanhang, die reine Version (ohne Revisionsanhang), die Revision bzw. Version mit Revisionsanhang ausgegeben. (Seit eix-0.29.5 ist es zulässig, nach diesen Optionen eine beliebige Anzahl von Argumenten anzugeben; bei mehr als einem Argument wird an jede Ausgabe ein Zeilenvorschub angehängt). Beispielsweise wird

split=1-font-adobe-75dpi-1.3-r1

PN=`versionsort -n "$split"`

P=`versionsort -p "$split"`

PF=`versionsort -f "$split"`

PV=`versionsort -v "X$split"`

PR=`versionsort -r "X$split"`

PVR=`versionsort -V "X$split"`

die Variablen PN, P, PF, PV, PR, PVR analog wie in ebuilds definieren: Als 1-font-adobe-75dpi, 1-font-adobe-75dpi-1.3, 1-font-adobe-75dpi-1.3-r1, 1.3, r1 bzw. 1.3-r1 (falls -r1 nicht angegeben worden wäre, wäre PR leer: Dies ist anders als in ebuilds).

Beachten Sie, dass versionsort nur bei den Optionen -n, -p und f erwartet, dass das Argument einen Paketnamen enthält: Bei allen anderen Optionen (oder ohne Option) wird durch Vorstellen des "X" klargestellt, dass es sich nicht um eine "reine" Versionsnummer handelt.

 

FEHLER (und Antworten auf einige häufig gestellte Fragen)

Für Fehlermeldungen benutzen Sie bitte https://github.com/vaeth/eix/issues/ oder Gentoos Bugzilla https://bugs.gentoo.org/

Viele Cache-Methoden sind prinzipbedingt sehr langsam. Benutzen Sie die Hinweise im speziellen Abschnitt BESCHLEUNIGUNG weiter unten.

eix kann nicht zuverlässig die Farbmöglichkeiten und Hintergrundfarbe Ihres Terminal feststellen; dies ist gerade dann besonders ärgerlich, wenn Sie ein transparentes Terminal benutzen oder die Vorgabe-Hintergrundfarbe von beispielsweise xterm auf Schwarz geändert haben. Hier sind einige einfache Methoden, wie sie einige ungewünschte Farbprobleme vermeiden können (zum Detailverständnis dieser Methoden schlagen Sie bitte die weiter oben stehende Beschreibung der Variablen TERM_ALT?, SOLARIZED, COLORSCHEME?, DARK, TERM_DARK und COLORFGBG_DARK nach):

1. Benutzen Sie das Farbschema zu ihrer tatsächlichen Hintergrundfarbe, indem Sie DARK=true oder DARK=false in /etc/eixrc setzen (oder in indem Sie die Heuristik aus TERM_DARK an Ihr System anpassen.)

2. Erzwingen Sie die korrekte Hintergrundfarbe (oder vermeiden Sie deren Setzen), indem Sie BG0=black, BG1=black, BG2=white, BG3=white (oder BG0=none, BG1=none, BG2=none, BG3=none) in /etc/eixrc setzen. Beachten Sie, dass das Erzwingen der Hintergrundfarbe transparente Terminals intransparent machen kann und dass darüberhinaus bei einige Terminals auch neu hereingescrollte Zeilen in dieser Hintergrundfarbe sein können. Um die erzwungene Hintergrundfarbe bei jedem Zeilenende (nicht) zurückzusetzen, können Sie RESET_ALL_LINES=false bzw. RESET_ALL_LINES=true setzen (die Vorgabe kann von der eix-Version abhängen).

3. Erzwingen Sie ein gewünschtes Farbschema auf allen Terminals indem Sie TERM_ALT3=. in /etc/eixrc setzen; dies kann mit COLORSCHEME3=0 (oder =1, ..., =5) kombiniert werden. Beachten Sie, dass die Farbschemas 0 und 2 sehr armselig sind, da sie nur die wenigen Systemfarben benutzen und daher verschiedene Dinge farblich nicht immer unterscheidbar sind. Dennoch kann dies sinnvoll sein, wenn Sie beispielsweise regelmäßig verschiedene Terminals benutzen und sich nur an ein einziges Farbschema gewöhnen wollen oder wenn Sie Ethan Schoonovers originales Farbschema erzwingen wollen. Benutzer von Solarized sollten in jedem Fall SOLARIZED setzen und Farbscheme 5 (oder 4) benutzen:

4. Wenn Sie Ihr Terminal auf Ethan Schoonovers Solarized Farbschema (hell oder dunkel) konfiguriert haben, setzen Sie einfach SOLARIZED=true (oder light oder dark - bzgl. eix ist das alles äquivalent). Benutzen Sie den vorherigen Hinweis nur für den Fall zusätzlich, dass es ihnen nicht passt, dass für 256-farbige Terminals zusätzliche Farben benutzt werden.

5. Wenn Sie ein rxvt benutzen, das 256 Farben beherrscht, dass aber nicht TERM=rxvt-256color oder TERM=rxvt-unicode-256color setzen, setzen Sie TERM_ALT1_ADD=rxvt in /etc/eixrc.

eix beherrscht keine Abhängigkeiten und/oder USE-Flags und wird das vermutlich auch niemals tun. Insbesondere heißt dies, dass die Ausgabe von eix -u i.a. etwas anderes liefert als ein emerge update-Kommando - das Letztere ist zuverlässiger. Dies gilt insbesondere auch für das Upgraden von Paketen mit Slots. Die Variable UPGRADE_TO_HIGHEST_SLOT und händische Ausnahmen in /etc/portage/package.slot_upgrade_forbid bzw. /etc/portage/package.slot_upgrade_allow können benutzt werden, um diesen Nachteil von eix abzufedern.

eix beherrscht nicht alle Sets, die Portage unterstützt, und wird das vermutlich auch niemals tun. Derzeit scheint es, dass sogar der vorgeschlagene Weg, Sets in den Portagebaum über PROPERTIES=set einzubauen, von eix nicht unterstützt werden wird (weil eix Abhängigkeiten und USE-Flags kennen müsste, um dies zu unterstützen). Als eine Notlösung kann man manuell solche zusätzlichen Sets in /etc/portage/sets.eix definieren. Darüberhinaus beherrscht eix nicht das Lesen von sets.conf-Dateien und wird das vermutlich auch niemals tun. Falls zusätzliche sets/-Verzeichnisse etwa in einem Overlay angegeben wurden, müssen diese zusätzlichen Verzeichnisse manuell in /etc/eixrc zur Variablen EIX_LOCAL_SETS hinzugefügt werden. Der leichteste Weg zu Letzterem ist es, einen Eintrag der Art

EIX_LOCAL_SETS_ADD="/path/to/overlay1/sets /path/to/overlay2/sets ..."

nach /etc/eixrc zu schreiben (vgl. die frühere Beschreibung von EIX_LOCAL_SETS).

eix-diff ignoriert /etc/portage/profile. (Grund: Die gespeicherte Datenbank enthält nur den Maskierungsstatus entsprechend des ursprünglichen Profils, aber nicht das Profil selbst. Andererseits kann /etc/portage/profile nur dann interpretiert werden, wenn das Profil bekannt ist).

Die Ausgabe mit der Standardeinstellung OVERLAYS_LIST=all-used-renumbered ist irritierend, wenn man die Overlaynummer in einer eix-Variablen oder -Kommando-Argument benutzen will.

Es gibt keine Cachemethode, das die Information aller Overlays (für die es keinen Portage-Metadatencache gibt) schnell und zuverlässig holt: Man muss immer eines dieser beiden Extreme wählen. Die Standardeinstellung ist schnell, aber sie liefert oft falsche Slots und hat andere Probleme.

Das ganze EPREFIX/ROOT-Zeugs ist sehr verwirrend. Insbesondere wird eix durch die bloße Tatsache, viele dieser Variablen zu berücksichtigen, stets verwundbar gegen lokale Angriffe sein, wenn es in einer möglicherweise kompromitierten Environment gestartet wird.

Die frühere Vorgabe KEEP_VIRTUALS=true verwirrte viele Leute. Mit der neuen Vorgabe findet leider fast niemand heraus, dass dieses Feature existiert. :(

Es gibt zu viele Features: Dokumentation und Konfiguration sind zu kompliziert geworden. Andererseits gibt es immer noch eine Menge Dinge, die nicht konfiguriert werden können...

 

BESCHLEUNIGUNG

Alle Nicht-Metadaten-basierten Cachemethoden für eix-update sind entweder unzuverlässig (parse, parse*) oder langsam und unsicher (ebuild, ebuild*). Daher wird empfohlen, Metadaten zu erzeugen und sie für den Hauptbaum und alle Overlays zu benutzen. Die Vorgaben von eix sind so, dass diese Metadaten benutzt werden, sofern vorhanden (siehe CACHE_METHOD_PARSE) (Konfiguration ist nur im Falle des sqlite-Backends von Portage erforderlich). Im Wesentlichen gibt es zwei Arten möglicher Metdaten, die benutzt werden können:

1. Metadaten, die jeweils im Baum/Overlay gespeichert werden.

Diese Daten liegen im metadata/cache oder metadata/md5-cache-Unterverzeichnis von $PORTDIR bzw. vom entsprechenden Overlay.

2. Metadaten, die von Portage für jeden Baum/Overlay in /var/cache/edb/ gespeichert werden.

Diese Daten werden mit emerge --metadata erzeugt (und ihr Format hängt davon ab, ob Portage das sqlite-Backend benutzt).

Der Nachteil bei der Benutzung von Metadaten ist, dass sie vor dem Aufruf von eix-update generiert bzw. auf den neuesten Stand gebracht werden müssen, sobald der entsprechende Baum/Overlay geändert wird, sowie im Falle von den Metadaten von /var/cache/edb, dass sie zusätzlichen Platz benötigen.

Glücklicherweise muss man sich nicht um Metadaten um Hauptbaum kümmern, da das metadata/{md5-,}cache-Unterverzeichnis von $PORTDIR automatisch mit emerge --sync auf den neuesten Stand gebracht wird. Der lokale Overlay allerdings und etliche Overlays, die von layman o.a. behandelt werden, enthalten keine Metadaten (und selbst wenn sie es tun, sind diese nicht immer aktuell), und daher sollten Metadaten dieser Overlays generiert werden, um eix-update zu beschleunigen.

Vorsicht: Metadaten zu erzeugen ist ein Sicherheitsrisiko, da alle Ebuilds des Baums dazu ausgeführt werden! Andererseits müssen Sie Overlays ohnehin vertrauen, wenn Sie sie nutzen...

Ich empfehle nicht die Benutzung von emerge --metadata (obwohl dies automatisiert leich zum richtigen Zeitpunkt ausgeführt werden könnte, indem man eix-sync mit der Option -M benutzt: Man müsste nur die Zeile -M in /etc/eix-sync.conf einfügen), denn es wäre eine Verschwendung von Plattenplatz, die Metadaten des ganzen Portage-Baums als Duplikat nach /var/cache/edb zu speichern.

Stattdessen empfehle ich, die Metadaten in den Overlays bei jedem eix-sync zu aktualisieren. Dies kann ebenfalls automatisiert zu richtigen Zeitpunkt geschehen, aber es erfordert ein etwas komplizierteres Setup:

Für einen lokalen Overlay - der Einfachheit halber nehmen wir an, er liege in /usr/local/portage, und dass dieser Pfad in PORTDIR_OVERLAY enthalten ist - geht man wie folgt vor:

Als erstes muss man dem Overlay einen Namen geben, falls nicht bereits geschehen: Dieser kommt in des File /usr/local/portage/profiles/repo_name (das ggf. zu erzeugen ist). (Dieser Schritt sollte unabhängig von eix oder Metadaten ohnehin immer geschehen). Ich nehme ab jetzt an, dass dieser Name mein_lokaler_Overlay lautet.

Als zweites muss man angeben, welcher Typ von Metadaten gewünscht ist: Dazu kommt in die Date /usr/local/portage/metadata/layout.conf (die ggf. neu anzulegen ist), die Zeile

cache-formats = md5-dict

sowie, außer man hat Gründe das nicht zu tun, ebenfalls die Zeile

thin-manifests = true

Das erste weist Portage an nur die Metadaten in /usr/local/portage/metadata/md5-cache zu erzeugen/benutzen (was die neue Methode ist und der alten vorgezogen werden sollte). Die andere Zeile hat nichts mit Metadaten zu tun sondern bedeutet nur, dass die Manifest-Dateien im Overlay keine Checksummen der Dateien aus /usr/local/portage enthalten müssen/werden.

Ab jetzt kann man jederzeit durch den Aufruf

egencache --repo=my_local_overlay --update

oder (falls der Overlay über kein aktuelles profile/use.desc verfügt):

egencache --repo=my_local_overlay --update --update-use-local-desc

die Metadaten erzeugen bzw. auf den neuesten Stand bringen. Beachten Sie, dass für den Fall, dass der Overlay eclassen vom Hauptbaum benutzt, der obige Befehl auch dann ausgeführt werden muss, wenn sich die eclassen ändern, also nach jedem emerge --sync. Um den obigen Befehl automatisch im richtigen Moment auszuführen, gibt es mehrere Methoden:

Eine Methode besteht darin, ein ausführbares Shell-Skript in das Verzeichnis /etc/portage/repo.postsync.d/ zu legen, das egencache auf geeignete Weise in Abhängigkeit vom Repository-Namen $1 aufruft. Beispielsweise kann man ein ausführbares File /etc/portage/repo.postsync.d/50-egencache mit folgendem Inhalt anlegen:

#!/bin/sh

[ -z "$1" ] && exit

case $1 in

# Für Repositories "mv" und "local" auch profile/use.desc aktualisieren:

mv|local)

    exec egencache "--repo=$1" --update --update-use-local-desc;;

# Für alle anderen Repositories nur die Metadaten:

*)

    exec egencache "--repo=$1" --update;;

esac

Wenn dieses Shell-Skript ausführbar ist, wird egencache nach jedem emerge --sync aufgerufen.

Eine Alternative besteht darin, egencache (nur) automatisch bei jedem Aufruf von eix-sync auszuführen. Fügen Sie dazu die folgenden Zeilen in /etc/eix-sync.conf ein:

@StatusInfo 'Erzeuge Metadaten für mein_lokaler_Overlay<'>

@egencache --repo=mein_lokaler_Overlay --update --update-use-local-desc

In ähnlicher Weise können auch beispielsweise alle Overlays gehandhabt werden, die von layman aktualisiert werden: Fügen Sie einfach für jeden Layman-Overlay entsprechende egencache-Aufrufe in F</etc/eix-sync.conf> ein. (Seien Sie dabei allerdings nochmals gewarnt, dass dies ein Sicherheitsrisiko darstellt, weil es bedeutet, dass die Ebuilds in den Overlays bei eix-sync ausgeführt werden).

Unabhängig davon, welche Methode Sie verwenden: Für layman-Overlays gibt es noch ein weiteres Problem. Je nach Versionskontrollsystem des Overlays kann sich layman weigern, den Overlay zu synchronisieren, wenn Daten in das metadata/-Unterverzeichnis geschrieben wurden, oder layman kann dieses Verzeichnis beim Synchronisieren löschen.

Für Overlays, die mit git gehandhabt werden, kann dieses Problem folgendermaßen gelöst werden: Erzeugen Sie im Hauptverzeichnis dieses Overlays die Datei .gitignore (wenn sie nicht bereits existiert), and fügen sie ihr die beiden Zeilen

/.gitignore

/metadata/

hinzu: Dies bewirkt, dass das File .gitignore selbst sowie das Unterverzeichnis metadata (und sein Inhalt) von git/layman bei obigem Aufruf ignoriert (insbesondere nicht verändert) werden.

 

INSTALLATION

Es ist Gentoo-Politik, die CXXFLAGS und LDFLAGS des Benutzers nicht zu modifizieren. Es ist ebenfalls Gentoo-Politik Voreinstellungen nicht zu ändern, wenn sie auf andere Weise weise konfiguriert werden können.

Aus diesem Grund wurden viele ehemalige USE-Flags aus dem Gentoo Ebuild entfernt. Daher ist es sehr wahrscheinlich, dass Ihre ./configure-Optionen nicht für eix passen. Der Maintainer von eix empfiehlt sehr den Export von

EXTRA_ECONF=--enable-security --enable-new-dialect --enable-strong-optimization

(Am Ende des Abschnitts steht, wie man das am besten macht). Der Zweck ist es, CXXFLAGS und LDFLAGS auf eine Art zu modifizieren, die eix stark optimiert (und für gewöhnlich die Größe des Binärprogramms und entsprechende Speichernutzung enorm reduziert) und zudem so verändert, dass es einigermaßen sicher ist (bzgl. *FLAGS), die Programme als Benutzer root zu verwenden. Natürlich sind die damit gewählten *FLAGS etwas experimentell, aber eix ist so geschrieben, dass sie unterstützt werden sollten. Wem das zu experimentall erscheint, der kann natürlich --enable-strong-optimization durch --enable-optimization ersetzen. Man kann auch --enable-new-dialect weglassen. Beide Änderungen werden für gewöhnlich in schlechter optimiertem Code resultieren. Umgekehrt kann man auch --enable-security durch --enable-strong-security ersetzen, das einige (experimentelle) *FLAGS (falls vorhanden) auswählt, die die Sicherheit erhöhen, allerdings auf merkliche Kosten der Ausführungsgeschwindigkeit.

Wenn Sie für Systeme mit wenig Speicher kompilieren, kann es auch ratsam sein,

--without-dep-default

--without-src-uri-default

und/oder

--without-required-use-default

zu dem obigen EXTRA_ECONF hinzuzufügen. Letzteres ist ähnlich, wie wenn Sie DEP=false und/oder REQUIRED_USE=false einer Datei in /etc/eixrc/ setzen: Es reduziert den von eix benötigten Speicher, indem es das Speichern der entsprechenden Daten vermeidet.

Einige speziellere Optionen, die Sie zu EXTRA_ECONF hinzufügen können, sind

--enable-warnings --enable-strong-warnings --debugging

mit Ihrer offensichtlichen Bedeutung bzgl. *FLAGS. Weitere EXTRA_ECONF-Argumente, die früher die USE-Flags zugänglich waren, sind:

--enable-swap-remote (Vertauschen der Rollen der beiden Remote-Adressen von eix-remote)

--enable-separate-tools (build separate small binaries for the tools instead of linking them into the eix binaries)

Der eix Maintainer empfiehlt die Konfiguration des Paketmanagers, um die gewünschte EXTRA_ECONF automatisch beim Emerge von eix zu setzen. Für portage kann das wie folgt geschehen: Fügen Sie die Zeile

app-portage/eix eix-extra-econf.conf

der Datei /etc/portage/package.env (oder einer Datei in diesem Verzeichnis) hinzu. (Erzeugen Sie dabei diese Datei bzw. Verzeichnis falls es noch nicht existiert). Erzeugen Sie dann die Datei /etc/portage/env/eix-extra-econf.conf mit der gewünschten Zeile EXTRA_ECONF="...".

Alternativ kann eix vom mv overlay installiert werden. Damit erhält man zusätzlich die experimentelle Möglichkeit, eix mit dem meson Build-System (statt autotools) zu bauen. Falls dies auf Ihrem System läuft, ist es vorzuziehen, da es schneller ist und besser mit ccache zusammenarbeitet. Aktuell (zum Zeitpunkt, wo dieser Text entsteht) ist es nicht möglich, eix mit dem Ebuild aus dem Gentoo Hauptbaum mit meson zu bauen.

 

GESCHICHTE

eix war ursprünglich als portagedb bekannt. Der Name wurde geändert, weil ein Teil von Portage ebenfalls portagedb heißt, was für alle etwas verwirrend war.

Die Funktionalität von eix-update wurde früher durch eine Option -u von eix erreicht. Dies wurde dann für leichtere Wartbarkeit abgetrennt. So kam update-eix ins Leben. Inzwischen ist es das gleiche Programm, dessen Funktionalität durch den Aufrufnamen festgelegt wird, und der ursprüngliche Name update-eix wurde nach eix-update umbenannt.

Auch eix-diff hieß früher diff-eix, eix-remote hieß früher update-eix-remote, eix-layman hieß früher update-eix-layman, und eix-functions.sh hieß früher functions-eix.sh (und viel früher update-eix-functions.sh). Der Grund für all diese Umbenennungen ist ein konsistenteres Namensschema: Alle mit eix verbundenen Programme beginnen jetzt mit eix-* (nur mit Ausnahme von versionsort, das aber ohnehin mehr oder weniger unabhängig ist).

Falls Sie sich nicht an diese neuen Namen gewöhnen können, oder falls Sie alte Skripte haben, die die alten Namen benötigen, können Sie symbolische Links für die alten Namen benutzen; dies ist ausdrücklich zulässig, und es ist nicht geplant, die Unterstützung dafür fallenzulassen.

Früher gab es eine ./configure-Option, um solche symbolischen Links oder eine Erinnerung an ihre Entfernung automatisch zu installieren, aber diese Option wurde in eix-0.24.0 entfernt.

Durch die Einführung der %{*VARIABLE}-Syntax in eix-0.8.0 ist es nicht mehr vernünftig, verschiedene Variablennamen für eix und eix-diff zu benutzen. Daher wurden alle entsprechenden DIFF_*-Variablen entfernt.

Die Cachemethode metadata-flat hieß früher einfach nur metadata. Die Cachemethode assign hieß früher backport oder portage-2.1. Die Cachemethode flat hieß früher auch portage-2.0, und dieser Name wurde sogar bevorzugt. Die obsoleten Namen werden nach wie vor unterstützt.

portage-2.1 und portage-2.1.1 löscht nicht das alten dep-Cachedirectory, so dass eix mit der flat/assign-Cachemethode Pakete finden könnte, die es gar nicht mehr im Portagebaum gibt. Um dies zu vermeiden, hatte eix-sync den alten Cache gelöscht (rm -rf /var/cache/edb/dep/*). Da die meisten Nutzer diese Cachemethode nicht mehr benutzen müssen, und das Löschen des alten Caches den nächsten Start von Portage verlangsamt, ist dies nicht mehr die Vorgabe (aber immer noch als Option verfügbar, die man nach /etc/eix-sync.conf schreiben kann).

eix-sync benutzte früher gensync statt layman. In der Beschreibung von /etc/eix-sync.conf erfährt man, wie man das obsolete gensync benutzen könnte.

eix-sync unterstützt kein Loggen mehr; die Optionen -v und -V wurden entfernt. Damit werden Probleme wie unsichtbare Ausgaben bei EMERGE_DEFAULT_OPTS=--ask vermieden. Man muss jetzt selbst Ausgabeumleitungen benutzen, wenn man eix-sync in einem cronjob benutzen will.

Der Mechanismus, der jetzt über DEFAULT_MATCH_FIELD funktioniert, hat sich geändert. Die früheren (weniger mächtigen) Variablen MATCH_.*_IF und MATCH_ORDER werden nicht mehr unterstützt.

Die Variablen ADD_CACHE_METHOD und ADD_OVERRIDE_CACHE_METHOD sind nicht länger fest eingebaut, sondern werden nur implizit durch verzögerte Ersetzung in den Vorgaben von CACHE_METHOD und OVERRIDE_CACHE_METHOD ausgewertet. Insbesondere wird also Setzen der letzten beiden Variablen in /etc/eixrc ohne Hinzufügen der verzögerten Ersetzung " %{ADD_CACHE_METHOD}" bzw. " %{ADD_OVERRIDE_CACHE_METHOD}" den ersten Variablen ihre Bedeutung vollständig nehmen.

Vor eix-0.18.0 gab es keine anpassbaren Ausgabe von Versionen wie mit <installedversions:VAR> oder <availableversions:VAR>. Statt dessen gab es ein Parameterchaos für <installedversions:*> und eine große Liste von Varianten zur Ausgabe verfügbarer und installierter Versionen zur Benutzung in Skripten wie etwa <fullvailableversions> usw. Mittlerweile ist dies alles verschwunden: Die Variablen NAMEVERSIONS, EQNAMEVERSION, ANAMESLOT, ANAMEASLOT, NAMESLOT, NAMEASLOT, und DATESORT übernehmen die Rolle der früheren Varianten (wobei DATESORT ein verwandtes Beispiel aufzeigt, das früher nicht möglich war). Details findet man in der Beschreibung diesr Variablen in eix --dump. Der Effekt eines solchen Beispiels ist etwa hier zu sehen:

eix --format '<availableversions:ANAMESLOT:ANAMESLOT>' --pure-packages gcc

Siehe auch die Kommentare zur Option -I.

Seit eix-0.20.0 haben sich die logischen Verknüpfungen für AUSDRUCK dramatisch geändert: Jetzt sind nicht nur Klammern möglich sondern auch Ketten mit -a und -o werden nun links-assoziativ behandelt, was wohl die meisten Anwender intuitiv erwarten. Die Negation --not wird nun als logischer Operator behandelt, der einen neuen KLAMMER_ODER_TEST startet und nicht mehr als Teil der TEST_OPTIONEN (was oft zu Konfusion geführt hatte). Jetzt wird auch --pipe als Teil der TEST_OPTIONEN behandelt und induziert nicht mehr implizit logische Verknüpfungen.

Seit eix-0.20.1 werden die früher benutzten Dateien /etc/portage/package.*.nowarn als Standardeinstellung nicht mehr unterstützt: Sie wurden durch die einzige Datei/Verzeichnis /etc/portage/package.nowarn ersetzt. Um die alten Dateien weiterhin zu nutzen, kann man OBSOLETE_NOWARN=true setzen. Mit der Beschreibung der Variablen PACKAGE_NOWARN (in der Ausgabe von eix --dump) kann man verstehen, weshalb dies funktioniert.

eix-installed war Teil von eix-test-obsolete vor eix-0.22.4, was ziemlich verwirrend für Benutzer und schwer zu warten war, da diese beiden Aufgabe nichts gemeinsam hatten.

Das voreingestellt Fehlerverhalten von eix-sync hat sich in eix-0.23.10 geändert: Früher war die Option -F automatisch und konnte nicht abgestellt werden.

Bei <eix-0.25.6 gab es eine NEWLINE-Variable, die nach einem Paket einen automatischen Zeilenvorschub ausgeben konnte. Dieser Hack war nur für obsolete FORMAT-Strings eingeführt worden und wurde wieder entfernt.

Die Variablen COLORSTRING, COLORSTRING_ALT und TERM_ALT wurden durch die flexibleren Variablen COLORSTRING? und TERM_ALT? ersetzt.

In eix-remote vor eix-0.28.5 war die jetzige Option -x die Standardeinstellung. Diese erscheint nach wie vor ein vernünftige Standardeinstellung, aber das Feature irritierte Benutzer (einige hielten es sogar für einen Bug), so dass es jetzt manuell als Vorgabe festgelegt werden muss (durch Setzen von EIX_REMOTE_OPTS=-x in /etc/eixrc).

Das Hilsprogramm eix-header existiert erst seit eix-0.28.6; stattdessen hatte eix die Optionen --is-current, --print-overlay-path, --print-overlay-label und --print-overlay-data, die nun redundant wären und daher entfernt wurden.

Seit eix-0.29.6 gibt es die Optionen --format-verbose und --format-compact nicht mehr, denn deren Wirkung kann besser durch Exportieren der Environment-Variablen FORMAT_VERBOSE bzw. FORMAT_COMPACT erreicht werden. Statt dessen überschreibt die Option --format jetzt den FORMATSTRING unabhängig vom gewählten Format.

Sei eix-0.29.6 haben die Optionen --verbose und --compact nur noch Einschalt-Funktion; zum Ausschalten gibt es die neue Option --normal.

eix-functions.sh konnte früher nur ge-sourced werden; erst sei eix-0.32.2 ist eix-functions.sh auch ein Programm, dessen Ausgabe für die Benutzung mit "eval" gedacht ist.

Das Ebuild hat viele frühere USE-Flags entfernt, um einer allgemeinen Gentoo-Politik zu folgen. Der Maintainer empfiehlt daher stark die Benutzung von EXTRA_ECONF zur Installation.

 

ÜBERSETZUNG

Für eine einfache feste Übersetzung des voreingestellten FORMATSTRING in Ihre Sprache, genügt es die Variablen, die mit I18N_... beginning in /etc/eixrc oder ~/.eixrc zu setzen: Leiten Sie die Ausgabe von eix --dump-defaults in eine Datei um, um eine Liste aller Variablen zu erhalten: Einige der letzten sind diejenigen, die sie suchen, die mit I18N_.... beginnen.

Die Variablen, die mit I18N_COLUMN_.... beginnen, sind dabei speziell und können benutzt werden, die Spalten an ein neues Layout anzupassen, das aufgrund abweichender Länge verschiedener Übersetzungen notwendig sein kann. (Beachten Sie, dass die Formatierung der Spalten durcheinander geraten kann, wenn Sie für Ihre Übersetzung keine UT8-Kodierung benutzen!) SIe können die Default-Werte dieser Variablen in den entsprfechenden C_COLUMN_....-Variablen ablesen, die in der Nähe stehen (aber die für Übersetzungszwecke nicht verändert werden sollten). Normalerweise sollte es genügen, I18N_COLUMN_CONTENT und I18N_INST_COLUMN_CONTENT auf geeignete Zahlen umzudefinieren. Um sicherzugehen, dass alle Spalten korrekt sind, sollten Sie am Ende die Ausgabe der Kommandos

eix -vxe binutils

eix -ve binutils

eix -le binutils -oe sun-jdk

eix -xle binutils

eix -vle binutils

eix -xvle binutils

eix -vle sun-jdk

betrachten. Hierbei steht binutils für ein installiertes Paket mit Slots, während sun-jdk für ein maskiertes (mit Erklärung des Grunds in package.mask) steht.

Sobald Sie eine Übersetung fertig haben, können Sie Ihre geänderten Variablen an den Eix-Maintainer oder eix auf Github schicken, oder noch besser: Fügen Sie Ihre Sprache der Datei po/LINGUAS hinzu, rufen Sie contrib/make auf, um eine entsprechende po/*.po-Datei zu erhalten, und fügen Sie Ihre Übersetzung dieser Datei an jenen Stellen hinzu, die sich auf src/eixrc/def_i18n.cc beziehen.

Natürlich können Sie dabei gerne auch andere Texte dieser Datei übersetzen: Benutzer können auch für unfertige Übersetzungen der wichtigsten Meldungen dankbar sein!

Sie können Ihre neue po/*.po-Datei dem Eix-Maintainer schicken, oder noch besser: Sie können Ihre Änderung auf Github mit einem Pull Request machen.

 

AUTOREN

Hauptautoren des Programms:

Martin Väth <martin at mvath.de> (developer, current maintainer)

Emil Beinroth <emilbeinroth at gmx.net> (developer, previous maintainer)

Wolfgang Frisch <xororand at users.sourceforge.net> (inactive developer, initial author)

Roland Wittmann <linuxcommando at users.sourceforge.net> (inactive developer)

Viele weitere Autoren sind in der Datei AUTHORS zu finden.

 

SIEHE AUCH

portage(5), fnmatch(3), regex(7), emerge(1), esearch(1), qsearch(1), layman(8)

Die eix-Homepage https://github.com/vaeth/eix/ enthält weitere Informationen und Links.

---

 

Index

NAME

ÜBERSICHT

BESCHREIBUNG

OPTIMIERUNG, SPEICHER, SICHERHEIT

BEISPIELE

OPTIONEN

gemeinsame Optionen

Spezielle Informations-Optionen

Ausgabe-Optionen

Spezielle Optionen für eix

Optionen für AUSDRUCK

Operandenwahl

Match-Algorithmus

Layouts festlegen (siehe FORMATSTRING weiter unten)

Spezielle Optionen für eix-update

AUSGABE

Slots

Maskierung

eix-diff

FORMATSTRING

konditionelle Blocks

Paketeigenschaften

Escape-Folgen

Farben

Beispiele:

DATEIEN

/etc/eix-sync.conf

/etc/eixrc

EIXRC

EIX_SYNC_OPTS, EIX_SYNC_CONF, EIX_REMOTE_OPTS, EIX_LAYMAN_OPTS, EIX_TEST_OBSOLETE_OPTS

~/.eixrc

/etc/portage/sets.eix

/etc/portage/package.slot_upgrade_forbid

/etc/portage/package.slot_upgrade_allow

/etc/portage/package.{accept_,}keywords.nonexistent

/etc/portage/package.keywords.nonexistent

/etc/portage/package.mask.nonexistent

/etc/portage/package.unmask.nonexistent

/etc/portage/package.use.nonexistent

/etc/portage/package.env.nonexistent

/etc/portage/package.license.nonexistent

/etc/portage/package.accept_restrict.nonexistent

/etc/portage/package.cflags.nonexistent

/etc/portage/package.installed.nonexistent

/etc/portage/package.nowarn

/var/cache/eix/portage.eix

/var/cache/eix/previous.eix

/var/cache/eix/remote.tar.bz2 und /var/cache/eix/remote2.tar.bz2

masked-packages

Beispiele:

Optionen

versionsort

FEHLER (und Antworten auf einige häufig gestellte Fragen)

BESCHLEUNIGUNG

INSTALLATION

GESCHICHTE

ÜBERSETZUNG

AUTOREN

SIEHE AUCH

LinuxReviews : de Manual Page Archive : man1