eix¶
NAME¶
eix - a set of utilities for searching, diffing and updating a binary cache of your local portage-trees
SYNOPSIS¶
eix [common options] [OPTIONS] EXPRESSION
eix-update [common options] [eix-update options]
eix-diff [common options] OLD-CACHE [NEW-CACHE]
eix-sync
eix-test-obsolete
eix-remote
eix-layman
eix-installed-after
eix-installed
eix-functions.sh
versionsort
DESCRIPTION¶
eix-update generates a binary cache from your local portage-tree and overlays. eix searches this cache for packages that match the restricting criteria you specify in EXPRESSION; if you specify no such restriction, all packages are output, of course. eix-diff compares two binary caches and finds packages that were added, removed or for which the highest stable versions has changed.
All of these programs and scripts read the configuration files described later. eix-sync has an additional separate configuration file.
eix-sync can sync the portage/overlay trees and compare them with the old cache using eix-diff. To get more help on eix-sync call eix-sync -h and see the documentation of /etc/eix-sync.conf below. Note that the content of the latter can also be stored in the variable EIX_SYNC_CONF.
eix-test-obsolete is a script which calls eix several times to display the output of eix -tTc in a more organized manner.
eix-remote can sync an eix database from an external server and add/remove it to the current database. Note that to keep such remote data across eix-update calls you might want to set KEEP_VIRTUALS=true in /etc/eixrc. To get more help on eix-remote call eix-remote -h and see the documentation of /etc/eix-remote.conf below.
eix-layman can add or remove local layman overlays to the current database. You might want to use this if you do not source layman's make.conf in your local /etc/make.conf. To get more help on eix-layman call eix-layman -h. eix-layman is also meant as an example script how to use eix-functions.sh:
eix-installed-after is a simple script (with many comments) demonstrating some possibilities how a custom eix output format can be used. It outputs packages installed after (or before) the last (or first) emerge of a specific package/version. To get more help on this script call eix-installed-after -h.
eix-functions.sh are helper functions used by eix-sync, eix-remote, and eix-layman. You might want to use them for your own similar scripts. Note that immediately after sourcing eix-functions.sh you will probably want to call read_functions [ARGS] to source baselayout's functions.sh with the corresponding ARGS.
eix-installed is a simple script which outputs all installed packages (in their exact version) and can check for packages installed with/without repository or buildtime information (cf. the description of CHECK_INSTALLED_OVERLAYS and USE_BUILD_TIME). To get more help on eix-installed call eix-installed -h.
versionsort is a helper tool for scripts which cuts the version strings from its arguments and outputs them sorted according to the portage rules of version sorting. Details can be found near the end of the manpage.
EXAMPLES¶
The following examples are some useful but perhaps unusual applications of eix. They are listed here to give you an idea what unexpected things you can do with eix. Since the examples are meant to be copied from this manpage they are listed early. To understand how they work, you should read the full manpage, of course. For more examples see e.g. the script eix-installed-after which contains many comments.
cmd | eix '-|*' --format '<markedversions:NAMESLOT>'
Assuming cmd creates a list of the form category/name-version or =category/name-version, the above prints the corresponding list category/name or category/name:SLOT (depending on whether SLOTs need to be distinguished).
cmd | eix '-|*' --format '<markedversions:NAMEASLOT>'
Similar to the above, but print always category/name:SLOT even if SLOT may be redundant. (Mnemonic: Always).
eix '-I*' --format '<installedversions:NAMEVERSION>'
Print out installed packages, using the format category/name-version. Of course, you could replace NAMEVERSION also by NAMESLOT or NAMEASLOT to get another format. The only purpose of the I option in this context is to speed up the output slightly.
eix '-I*' --format '<installedversions:EQNAMEVERSION>'
Similarly to the above but in the format =category/name-version which you can pipe directly to portage.
eix '-I*' --format '<installedversions:DATESORT>' | sort -n | cut -f2-3
Print out installed packages (with slots if necessary), sorted by installation date. If you want the output in another format, you have to modify DATESORT correspondingly (you can see the original definition in the output of eix --dump).
This sorting trick works as follows: The DATESORT variable outputs as the first column the seconds since epoch (eix --print DATESORT will show you that this happens by the variable DATESORT_DATE whose first entry is %s), and sort thus gets the correct order by sorting alphabetically. Finally the cut command gets rid of this first column which was only needed for sorting.
In the above examples, things like NAMEVERSION and DATESORT are actually just names of variables which are predefined in eix (with eix --dump you see them). You can as well define your own variables and use them. To understand how this works, please read the manpage, especially the description of the FORMAT string. }}}
OPTIONS¶
Common options¶
These options are common to eix, eix-diff, and eix-update.
-h, --help
Print a help screen and exit.
-Q, --quick (toggle) (not for eix-update)
Do (not) read the slots of installed versions which cannot be guessed (i.e. installed versions of packages with at least two different slots for which the installed version is not in the database anymore). Note that with this option, eix and eix-diff might report false positives for up-/downgrade recommendations for these packages.
--care (not for eix-update)
This deactivates --quick, and moreover, slots of installed version are always read instead of relying on the guess of the slot. This will in particular make sure that you get an up-/downgrade recommendation if a slot name of an installed version changes. Note that this will dramatically decrease the speed at the first call. (If your filesystem has a reasonable cache, later calls are almost not slower than without this option.)
-q, --quiet (toggle)
Produce no output on stdout. For eix you can decrease execution time by combining this (depending on your needs) with either --brief or --brief2 and by setting COUNT_ONLY_PRINTED=false. See also NOFOUND_STATUS and MOREFOUND_STATUS
--dump
Show the current eixrc-variables, and their defaults as comments; then exit.
--dump-defaults
Show the defaults of the eixrc-variables, and their current values as comments; then exit.
--print VAR
Print the specified variable VAR of eixrc or of portage settings, completely expanded as it would be used internally by eix; then exit. This is mainly intended for usage in scripts or for debugging purposes. If you use it in scripts you might want to specify PRINT_APPEND to get trailing spaces (see description of PRINT_APPEND).
-V, --version
Print version and exit.
-n, --nocolor
Disables the use of ANSI color codes. This is useful for terminals that do not support ANSI colors. (This is automatically turned on if stdout is no tty, but can be overridden by using --force-color)
-F, --force-color
The opposite of --nocolor.
Special information options¶
The following special information options are only provided by the eix binary. They are one-shot exclusive options, i.e. eix outputs only the required data and then exits.
--print-overlay-path OVERLAY
Print the path of the first overlay matching OVERLAY. OVERLAY may be an overlay label, an overlay path (mask) or a number.
--print-overlay-label OVERLAY
Print the path of the first overlay matching OVERLAY. OVERLAY may be an overlay label, an overlay path (mask) or a number.
--print-all-useflags
print all IUSE words used in some version.
--print-all-keywords
print all KEYWORDS used in some version.
--print-all-slots
print all SLOT strings used in some version.
--print-all-provides
print all PROVIDE words used in some package.
--print-all-licenses
print all LICENSE strings used in some package.
--print-world-sets
print the world sets.
--is-current
This checks only whether /var/cache/eix is available and valid (i.e. in a version supported by the eix binary). If this is the case, eix returns successful without printing anything.
Output options¶
-x, --versionsort (toggle)
Prints available versions sorted by slots/versions. If sorted by slots, each new slot starts in a new line.
-l, --versionlines (toggle)
Prints available versions in a (vertical) list. Moreover, the IUSE data is printed for each version (and not collected for the whole package).
-c, --compact (toggle)
Causes eix to use a compact layout for search results. Useful for obtaining a better overview in the case of a long list of results, and also to help speed up searching over slow connections such as a serial console.
-v, --verbose (toggle)
Use a verbose layout with additional information about search results such as the license of a package.
--xml (toggle)
Output in XML format. If you use this option from an external program you will probably want to combine this with --care and export some variables like LOCAL_PORTAGE_CONFIG to make sure that the preferred user output settings do not influence your output. If this option is active, OVERLAYS_LIST=none and --pure-packages are automatically active. The output format can be slightly influenced by the XML_* variables. The XML format used is documented in human-readable form in the files eix-xml.html or eix-xml.txt and in less human-readable form (namely as an xml-schema) in the file eix-xml.xsd
-*, --pure-packages (toggle)
(do not forget quoting if you use the short form from within a shell.) Omit printing of additional information (overlay names, number of found packages) after the packages. This might be useful for some shell scripts parsing the output
--only-names (toggle)
As "-*", but additionally print only the category and name of the packages found.
-0, --brief (toggle)
Print at most one package then stop. This option is typically faster when used with COUNT_ONLY_PRINTED=false. In the latter case, when you use fuzzy search, not necessarily the best match is output.
--brief2 (toggle)
As --brief, but print up to two packages.
Special options for eix¶
-t, --test-non-matching
Before other output, print entries of /etc/portage/package.* which do not match any existing version in the package database or which apparently have no meaning because they are empty (see TEST_FOR_EMPTY).
This option also lists all installed packages whose name is not in the database.
Note that this is essentially different from -T (see below). The latter only tests for packages in the database whether redundant entries in /etc/portage/package.* exist or whether the installed versions are available, respectively.
This option is best combined with -T to clean up /etc/portage/package.*
Or you can combine it with -e to have no other output.
If you have a reason to exclude certain entries/packages from this test, you can write those entries into a file /etc/portage/package.*.nonexistent where *=keywords,mask,unmask,use,env,cflags,installed. These files (and how to modify their filenames) are described later.
--cache-file FILE
Use FILE instead of /var/cache/eix.
Options for EXPRESSION¶
A EXPRESSION is used to narrow which packages eix prints.
An EXPRESSION can contain Boolean operators and tests according to the following grammar:
EXPRESSION ::= [ --not | -! ] BRACE_OR_TEST |
EXPRESSION [ --and| -a ] EXPRESSION |
EXPRESSION [ --or | -o ] EXPRESSION
BRACE_OR_TEST ::= --open|-( EXPRESSION --close|-) |
TEST_WITH_OPTIONS
TEST_WITH_OPTIONS ::= [TEST_OPTIONS] [PATTERN]
Do not forget that !, (, ) have to be quoted in shells so that eix actually receives these as parts of arguments!
If you want that an EXPRESSION starts with -, precede it with two further -- symbols: This way, the EXPRESSION is not read as an option, and two additional -- symbols are ignored. For example, eix ---tool --or ---util will output the packages containing -tool or -util.
The meaning of the logical operators should be obvious with perhaps some exceptions:
1. If neither --and|-a nor --or|-o is between two EXPRESSIONs, then one of them is implicitly assumed; whether this is -a or -o depends on the setting of the configuration variable DEFAULT_IS_OR.
2. The operators -a and -o have equal precedence and are left-associative. In particular, X -o Y -a Z fails if Z fails.
3. --not|-! negates only the result of the subsequent BRACE_OR_TEST.
4. If PATTERN is omitted, it defaults to the empty PATTERN. For instance, with the default settings, eix without arguments will match all packages, since the empty string is contained in every name. On the other hand, eix -e should (usually) output nothing, because no package name should exactly be the empty string.
5. Note that the syntax implies that PATTERN always ends an expression. TEST_OPTIONS after PATTERN always start a new expression (i.e. an implicit --and or --or is inserted, depending on DEFAULT_IS_OR). In particular eix -e foo has a different meaning than eix foo -e. The latter means the same as eix foo --and -e or eix foo --or -e, depending on DEFAULT_IS_OR.
6. Observe that TEST_OPTIONS can consist of several options. All of these options are applied simultaneously, i.e. in a sense these options are logically braced and combined with and (independently of DEFAULT_IS_OR) This is somehow ambiguous, since PATTERN can be omitted. This ambiguity is resolved by interpreting successive TEST_OPTIONS always as a part of one TEST_WITH_OPTIONS. For instance, in eix -I -O -e foo all options are considered as part of a common EXPRESSION (not as four EXPRESSION as would be the case for eix -I '' -O '' -e '' foo). On the other hand, in eix -I --not -e the --not will cause the subsequent TEST_OPTION -e to be considered as part of a new EXPRESSION. Options other than TEST_OPTIONS or a logical option (like -!, -(, -), -a, -o) are ignored in this respect. For instance, eix -I -c -e generates only one EXPRESSION, since -c is neither a TEST_OPTION nor a logical option and therefore plays no role for the interpretation of EXPRESSION.
7. The TEST_OPTIONS can specify things like the match algorithm and also operation selection. All these specifications refer only to the current TEST_WITH_OPTIONS, in particular, they are only active for the next PATTERN.
Note that besides using this expression syntax a different way of implicit (though slow) package selection on various other criteria is possible by defining FORMATSTRING (see below) using conditionals such that it outputs an empty string for the undesired packages.
Here are the admissible TEST_OPTIONS:
-I, --installed
Only match installed packages. Please do not use this as a replacement for eix-installed -a (or qlist -ICv or equery), it is not the same: Packages that are installed, but no longer in the portage tree (or an overlays) are not listed here. However, you should better not have such packages at all (better put these packages in overlays in case you need to reinstall them). To find such packages, you can use eix -te (or eix -tI to get listed both) but be aware that eix -t does not obey the usual FORMAT rules for these packages. So you better do not use this in scripts unless you know what you are doing.
If you really want to use this option as a substitute for equery in scripts, you might want to combine it with some of
--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
Only match packages which are installed in at least two different versions. Usually, this means that these versions are slotted (at installation time).
-d, --dup-packages
Only match duplicated packages, for example, if sys-foo/bar exists both in the official portage tree and a local overlay. If DUP_PACKAGES_ONLY_OVERLAYS is set (see below), the instances must be in two different local overlays.
-D, --dup-versions
Only match packages with duplicated versions, for example, if sys-foo/bar-0.2.1 exists both in the official portage tree and a local overlay. If DUP_VERSIONS_ONLY_OVERLAYS is set (see below), both instances must be in overlays.
-1, --slotted
Only match packages with a nontrivial slot, i.e. where SLOT is nonempty and different from "0".
-2, --slots
Only match packages with at least two different slots. In contrast to -1, a package is not shown here, if only one slot is available with e.g. slot-name "4.3".
-u, --upgrade, --upgrade+, --upgrade-
Only match packages which have at least one slotted version installed which is not the best version within that slot. This means usually that you should either upgrade or downgrade that package.
However, the test takes also UPGRADE_TO_HIGHEST_SLOT (see below) into account.
If you use --upgrade+ or --upgrade-, then the test acts as if LOCAL_PORTAGE_CONFIG is true or false. Otherwise, this decision is based upon UPGRADE_LOCAL_MODE.
If you want to see only packages with downgrade recommendations, you might make use of the FORMATSTRING features described below.
--stable, --testing, --non-masked, --system, --system-plain+
Only match packages which have at least one version which is stable (and non-masked), testing or stable (and non-masked), non-masked, in system or provides a system virtual, or in system, respectively. If several of these options are combined in one test, it is the same version which must satisfy all.
--stable+, --testing+, --non-masked+, --system+, --system-plain+
This is as the above ones just that the test acts as if LOCAL_PORTAGE_CONFIG=true.
--stable-, --testing-, --non-masked-, --system-, --system-plain-
This is as the above ones just that the test acts as if LOCAL_PORTAGE_CONFIG=false.
--installed-unstable, --installed-testing, --installed-masked
Only match packages which have at least one version installed which has at least one non-stable, testing, or masked version installed (the test acts as if LOCAL_PORTAGE_CONFIG=false). If several of these options are combined in one test, it is the same version which must satisfy all.
--world, --world-plain
Only match @world packages (and in case --world also those providing virtuals for @world). This is analogous to "emerge @world", i.e. it includes not only packages in the world file but also in world sets and the @system set. If you do not want to have all included, choose the appropriate alternative option.
--world-file, --world-plain
This only matches packages from the world file or from the @system set. In case --world-file also those providing corresponding virtuals are accepted.
--world-set, --world-set-plain
This only matches packages from world_set or from the @system set. In case --world-set also those providing corresponding virtuals are accepted.
--selected, --selected-plain
Only match @selected packages. This is analogous to "emerge @selected", i.e. it includes not only packages in the world file but also in world_sets (if you have @system contained in the world_sets file, then the behaviour is of course identical to --world). The --selected variant also includes packages providing corresponding virtuals. If you do not want to have both included, choose the appropriate alternative option.
--selected-file, --selected-file-plain
This only matches packages from the world file. The --selected-file variant also includes packages providing corresponding virtuals.
--selected-set, --selected-set-plain
This only matches packages from world_set. The --selected-set variant also includes packages providing corresponding virtuals.
--binary
Only match packages with a binary file (*.tbz2) in PKGDIR. The version of the binary file must either match the version of an available version or of an installed version. (However, note that if no version is available, the package cannot be found either). Just the existence of the corresponding *.tbz2 file is checked: Whether portage can actually use the file depends also on metadata within the *.tbz2 file (like USE settings) which is not considered by eix.
-O, --overlay
Only match packages with at least one version in an overlay.
--in-overlay overlay
Only match packages with at least one version in an overlay matching overlay.
If this option is repeated, the additional overlay arguments are joined to the list of admissible overlays.
overlay may be either a wildcard pattern or a number. Note that if you use the default OVERLAYS_LIST=all-used-renumbered you do not see the correct overlay numbers; to get a list of the correct overlay numbers you can e.g. call
OVERLAYS_LIST=all eix --not
or in scripts better
OVERLAYS_LIST=all PRINT_COUNT_ALWAYS=never eix -!
The special values 0 or $PORTDIR match the "main" tree (which in this connection is considered as the 0'th overlay).
If overlay is empty (or omitted if --in-overlay is the last option) it matches all overlays except for the "main" tree (i.e. --in-overlay '' is the same as -O).
--only-in-overlay overlay
Only match packages which have only versions in an overlay matching overlay.
If this option is repeated, the additional overlay arguments are joined to the list of admissible overlays.
overlay may be either a wildcard pattern or a number, as in --in-overlay. As particular, --only-in-overlay '' matches all packages which are not in the official portage tree but only in some overlay.
-J, --installed-overlay
Only match packages which have been installed from some overlay. To get a completely reliable result you should set CHECK_INSTALLED_OVERLAYS to true (which is not the default because it dramatically slows down the test). See CHECK_INSTALLED_OVERLAYS for details.
--installed-from-overlay overlay
This is analogous to --in-overlay with the difference that only packages are matched which have at least one version installed from overlay. For instance, --installed-from-overlay 0 will only match those packages which have at least one version which was installed from the regular portage tree. As for -J, you should set CHECK_INSTALLED_OVERLAYS to true to get a completely reliable result.
--installed-in-some-overlay
Only match packages with at least one installed version number which is also in some overlay.
--installed-in-overlay overlay
This is analogous to --in-overlay with the difference that only packages are matched which have at least one installed version in overlay. For instance, --installed-in-overlay 0 will only match those packages which have at least one version which is also in the regular portage tree.
--restrict-fetch
Only match packages which have at least one version with RESTRICT=fetch. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-mirror
Only match packages which have at least one version with RESTRICT=mirror. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-primaryuri
Only match packages which have at least one version with RESTRICT=primaryuri. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-binchecks
Only match packages which have at least one version with RESTRICT=binchecks. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-strip
Only match packages which have at least one version with RESTRICT=strip. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-test
Only match packages which have at least one version with RESTRICT=test. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-userpriv
Only match packages which have at least one version with RESTRICT=userpriv. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-installsources
Only match packages which have at least one version with RESTRICT=installsources. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-bindist
Only match packages which have at least one version with RESTRICT=bindist. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--restrict-parallel
Only match packages which have at least one version with RESTRICT=parallel. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--properties-interactive
Only match packages which have at least one version with PROPERTIES=interactive. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--properties-live
Only match packages which have at least one version with PROPERTIES=live. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--properties-virtual
Only match packages which have at least one version with PROPERTIES=virtual. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
--properties-set
Only match packages which have at least one version with PROPERTIES=set. If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
-T, --test-obsolete
Only match obsolete packages.
Packages are obsolete if they have redundant entries in /etc/portage/package.* (if TEST_FOR_REDUNDANCY is true) or if not all installed versions exist (if TEST_FOR_NONEXISTENT is true).
What is considered as redundant is defined by the REDUNDANT_IF-variables below, and what is considered as non-existent is defined by the NONEXISTENT_IF-variables. Note that the test for versions from obsolete overlays works only reliable if you set CHECK_INSTALLED_OVERLAYS to true (which is not the default because it dramatically slows down the test). See CHECK_INSTALLED_OVERLAYS for details.
Note that this options only tests packages in the database - in particular, you will not find entries for e.g. renamed or removed (from the portage tree) packages with this option. Use -t to find the latter.
Therefore, this option is best combined with -t to find also other types of obsolete entries.
If you have a reason to exclude certain packages from this test, you can write those entries into a file (or directory) /etc/portage/package.nowarn This file (and how to specify alternative/additional files) is described later.
-|, --pipe
(Recall that a shell will not pass an unquoted | sign, so quote properly).
Only match packages from standard input; usually you will want to use this in a pipe, redirected e.g. from emerge -pv (similar to genlop -p). Actually, any input data is honored which contains words (space or newline separated) in the format
category/package-version or
category/package
In addition, all packages/versions passed this way will in the output be considered marked. For details on the latter, see the marked and markedversions:* formatstrings.
Even if --pipe occurs more than once, the standard input is of course only read once, but interpreted repeatedly for each occurrence (i.e. if the first --pipe matches, all others will also match).
If you want to use the standard input only for marking but not for selection, you can choose an expression like
eix something -a "-(" --pipe -o "-)"
Match field selection¶
The subsequent options define the fields that the pattern should be tested on.
Multiple fields may be specified in one expression (the expression matches if the pattern matches at least one of the specified fields). If you do not specify some of these options, the default is chosen according to some heuristic depending on the form of your pattern. In most cases, the default match field will be --name, but if your pattern looks "special" like e.g. "cat/n" or "@set", the default match field will change to --category-name, --set, --description, --homepage, --virtual, or --license. Details of the heuristic are specified by the DEFAULT_MATCH_FIELD configuration variable explained later.
-s, --name
e.g. "eix"
-S, --description
e.g. "Small utility for searching .."
-C, --category
e.g. "app-portage"
-A, --category-name
e.g. "app-portage/eix"
-H, --homepage
e.g. "http://eix.berlios.de/"
-L, --license
e.g. "GPL-2"
-P, --provide
e.g. "virtual/blackbox"
--set
Name of a local package set of a version in the database (i.e. corresponding to a file in /etc/portage/sets, /etc/portage/sets.eix, or from another directory specified in EIX_LOCAL_SETS_ADD; see the comments to EIX_LOCAL_SETS). The "system" and "world" sets are intentionally excluded here, since the latter should be tested with --system[+-], --world, --world-all, or --world-sets.
--slot
Slotname of a version in the database, e.g. "kde-4"
--installed-slot
Slotname of an installed version. Recall that without option --care (or CAREMODE=true) the slotname might be guessed.
-U, --use
A useflag defined by IUSE in some version by some of the ebuilds of the package. You will usually want to combine this option with -e
--installed-with-use
A useflag enabled during installation of the package. Of course, this flag can only match if the package is installed. Note that the same restrictions hold as for -I, i.e. only packages will be matched which are still in the database.
--installed-without-use
A useflag disabled during installation of the package. Of course, this flag can only match if the package is installed. Note that the same restrictions hold as for -I, i.e. only packages will be matched which are still in the database.
Match algorithm¶
The subsequent options define the algorithm by which the match field should be tested against the expression. Only one algorithm can be chosen for an expression. If you do not specify some of these options, the default is chosen according to some heuristic depending on the form of your search pattern. In most cases, the default will be --regex unless your expression "looks" like a glob pattern or a substring (in which case the corresponding algorithm will be the default), or if the pattern has a particular content like "@set" or "cat/n" which most people would expect to match the whole string or the beginning of a string, respectively. Details of the heuristic are specified by the DEFAULT_MATCH_ALGORITHM configuration variable explained later.
-e, --exact
Pattern is an exact (full) string. For example, "eix -e gcc" will only show packages with the name "gcc".
-b, --begin
Pattern is the beginning of the string. For example, "eix -b gcc" will show the package with the name "gcc" but also e.g. "gcc-config".
--end
Pattern is the end of the string.
-z, --substring
Pattern occurs somewhere within the string.
-f [N], --fuzzy [N]
Do a fuzzy search with a maximal levenshtein-distance of N (default ) for the full string. Note that this command slows down search speed.
-p, --pattern
pattern is a wildcard-pattern (for the full string). See fnmatch(3) and/or glob(7) for further information. Be sure to use single quotes around patterns (to prevent the shell from intercepting any wildcards).
-r, --regex
pattern is a regexp. Only a substring must be matched (unless ^ or $ are used); the empty pattern matches everything. For further information, please read regex(7). Again, be sure to use single quotes around patterns.
Defining layouts (see FORMATSTRING below)¶
--format FORMAT
Define the normal layout for results as FORMAT
--format-compact FORMAT
Define the compact layout for results as FORMAT
--format-verbose FORMAT
Define the verbose layout for results as FORMAT
Special options for eix-update¶
-o outputfile, --output outputfile
With this option, eix-update will write the eix database to outputfile instead of /var/cache/eix, without testing or changing any permissions of that file.
-a overlay, --add-overlay overlay
This is similar to adding overlay to PORTDIR_OVERLAY in /etc/make.conf or to ADD_OVERLAY but has the advantage that you need not modify some of those, and you can also use spaces in overlay. Overlays added by this option come after overlays added by KEEP_VIRTUALS. If overlay is already contained in the list of overlays, this option has no effect. It is explicitly admissible to use this option repeatedly to add several overlays.
-x overlay, --exclude-overlay overlay
This is similar to adding overlay to EXCLUDE_OVERLAY but has the advantage that you need not modify the latter, and you can also use spaces in overlay. overlay is considered as a mask. All matching overlays (even those added by later --add-overlay options) are excluded from the list of overlays. The PORTDIR directory is considered as any other overlay which can be excluded (in this case, the first overlay in the list will be stored as PORTDIR). It is explicitly admissible to use this option repeatedly to exclude several overlays.
-m overlay method, --override-method overlay method
Change the cache method of overlay (the PORTDIR directory is an allowed overlay) to method. overlay is considered as a mask, i.e. it may contain wildcards. If overlay does not match anything in the list of overlays, this option has no effect. This option is similar to adding the entry "overlay method" at the end of the OVERRIDE_CACHE_METHOD variable. It is explicitly admissible to use this option repeatedly to override cache methods for several overlays. The last matching override takes precedence. In particular, the option overrides the content of OVERRIDE_CACHE_METHOD.
-r overlay-path overlay-label, --repo-name overlay-path overlay-label
The overlay overlay-path obtains the label overlay-label, independent of any other settings. This may be overridden by REPO_NAMES. In contrast to REPO_NAMES, overlay-path is not a pattern but the exact path.
OUTPUT¶
Slots¶
In contrast to usual output of versions in emerge, eix can also print slot names if they are nonempty and different from "0". Whether this happens is determined by the content of the FORMATSTRING.
If slots are printed, the slot name is separated from the version number either with a colon, or the slot names are written in braces. You can choose the preferred modes with the COLON_SLOTS variable.
If PROPERTIES or RESTRICT are set in the ebuild, this is shown by default in the version string; details can be influenced by setting of configuration variables.
Some Examples:
4.1.1:4.1 or 4.1.1(4.1)
This is version 4.1.1 which will be installed into the slot "4.1".
3.14p:GNAT-3.14p or 3.14p(GNAT-3.14p)
This is version 3.14p which will be installed into the slot "GNAT-3.14p".
2.0.0_rc1-r6
This is version 2.0.0_rc1-r6, and SLOT is either empty or "0".
1.0+i+l+v+s!f!m!p!b!s!t!u!i!d!P{tbz2}
This is version 1.0 which is subject to PROPERTIES="interactive live virtual set" as well as RESTRICT="fetch mirror primaryuri binchecks strip test userpriv installsources bindist parallel" Moreover, a *.tbz2 file (binary package) exists for that version in PKGDIR.
5.0-r3(5.0R3)!f
This is version 5.0-r3 which will be installed into SLOT 5.0R3 and has fetch restrictions.
Masking¶
If you used gentoo for more than a week you're probably going to immediately recognize the format of the masking in the version-strings. Nevertheless, we are going to explain it here by some examples. We describe here of course only the default setting; details can be influenced by setting of configuration variables.
[P]2.95.3-r8
If a mask for the package was found in the packages-files from your profile, but this version does not match it, the version is determined to be "masked by profile".
[M]4.0.0_alpha20050213
The version matches a mask from /etc/portage/package.mask, $PORTDIR/profiles/package.mask or a package.mask from your profile. Portage calls this "masked by package.mask".
[m]4.1.4
The version matches a local mask (from /etc/portage/package.mask), but it is neither "masked by profile" nor masked in $PORTDIR/profiles/package.mask.
{P}2.95.3-r8
The version was originally "masked by profile", but this was locally changed in /etc/portage/profile/packages.
{M}4.0.0_alpha20050213
The version was originally masked in $PORTDIR/profiles/package.mask, but this was locally changed in /etc/portage/package.unmask.
*3.3.3
This means the version is "masked by missing keyword" but stable for an alien architecture.
~*3.3.3
This version is "masked by missing keyword", stable on no architecture, but unstable on an alien architecture.
**3.3.3
This means the version is "masked by missing keyword" for all architectures.
(**)3.4.3-r2
That version originally had no keyword, but this was locally changed (in /etc/portage/package.keywords or by ACCEPT_KEYWORDS).
-*3.4.3-r2
That version is "masked by -* keyword" for all architectures (soon obsolete).
-0.8.14
Masked by -ARCH.
~3.3.5.20050130
The version would be "masked by ~keyword".
(~)3.3.5.20050130
The version was originally "masked by ~keyword", but this was locally changed (in /etc/portage/package.keywords or by ACCEPT_KEYWORDS).
[M]~1.0.9626
The version is both, "masked by package.mask" and "masked by ~keyword".
[m](~)4.1.4-r1
The version was originally only "masked by ~keyword", but this was locally changed (in /etc/portage/package.keywords or by ACCEPT_KEYWORDS). However, the version is locally masked (in /etc/portage/package.mask).
3.3.1
Finally, this would be a stable version (which would be stable also without the local settings).
eix-diff¶
The output of eix-diff is completely determined by configuration variables (DIFF_FORMAT_NEW, DIFF_FORMAT_DELETE, DIFF_FORMAT_CHANGED and a lot of variables which - at least in their default setting - is used by them via delayed substitution, see below). The following explanation by means of examples therefore can only describe the behavior in the default setting of the current eix version. Although this default format was not changed for quite a while, no stability of the defaults is guaranteed for future eix versions.
[N] >> foo/bar (~1.0): description of foo/bar
The package foo/bar has freshly appeared in the tree.
[*N] >> foo/bar (1.0): description of foo/bar
The package foo/bar has freshly appeared in the tree. Moreover, it has a version (1.0) which could be installed without any sort of unmasking/keywording.
<< foo/bar ({M}1.0): description of foo/bar
foo/bar was removed from the tree; the previous version 1.0 was masked, but it is currently not masked anymore (probably, because the developer has cleaned up the package.mask file with the removal of the package).
[*>] == foo/bar (1.0): description of foo/bar
The status of package foo/bar has changed in the tree (for your settings): It has gained a version (1.0) which could be installed without any sort of unmasking/keywords while in the previous tree foo/bar had no such version. Moreover, the > means that one slot has gained a higher version. In this case, it is actually the same change which is responsible for both symbols > and *.
[><] == foo/bar (1.1(1) 2.0(2) -> 1.0(1) 2.1(2)): description
The status of package foo/bar has changed in the tree (for your settings): The symbols on the left mean that one slot has gained a higher version which could be installed without modifying masks/keywords, another slot had such a highest version removed. If you consider the version strings, it becomes clear that slot 2 has obtained a new version (the previous stable in this slot was 2.0, the new one is 2.1), and that the previously highest stable version 1.1 of slot 1 was removed or masked (the current stable version in this slot is now 1.0).
[UD] == foo/bar (1.1(1)@01.01.2009; 1.1(1) -> 2.0(2)): description
The status of package foo/bar has changed in the tree (for your settings): The symbols on the left mean the one slot you have installed can be upgraded (without modifying masks/keywords), and that another slot you have installed was removed/masked. Looking at the versions on the right, it becomes clear that the installed version 1.1 of Slot 1 has been removed or masked, and that there is no other installed version of slot 1. However, a new stable version 2.0 in slot 2 has appeared (i.e. slot 2 did previously not exist or had no stable version).
Since no version of slot 2 was installed yet, eix cannot decide in this situation whether the symbol "U" is really appropriate: Since eix does no dependency tracking, it does not know whether the new slot would be pulled in e.g. by your world file, or whether there is only some dependency to your old slot. Therefore, the symbol "U" is only shown in this situation if UPGRADE_TO_HIGHEST_SLOT=true or if the package is listed in /etc/portage/package.slot_upgrade_allow.
Actually, the output == foo/bar ... would be more consistent, because in addition one slot has gained a higher stable version and the highest stable version of another slot was removed, but since typically this is implicitly implied by "U" or "D", respectively, it was a design decision of the default setting that if U or D is output then the symbols < and > will never output. You can of course build a different DIFF_FORMAT_HEADER_CHANGED string which follows another policy.
FORMATSTRING¶
A formatstring can contain conditional blocks, package properties, colors and normal strings. If a formatstring expands to the empty string for a package, also the trailing newline is not printed. Thus you can put the whole formatstring into a conditional block to output only packages matching the conditional. An example of this wrapping is given below.
Conditional blocks¶
Conditions are very simple: A property is expanded and the resulting string is tested against another string. If they are the same, the condition is true and the block is executed. Conditions can be negated so that the else-part is executed if the condition is true, and the if-part if the condition is false. The else-part can be also be completely left out.
{[!]PROPERTY[=RHS']}TCODE{}
Execute TCODE if the string resulting from expanding PROPERTY is equal to RHS. The ! would negate the behaviour. RHS is either a property (if enclosed in <>) or a variable (if prefixed with $) or a string (otherwise or if quoted).
{[!]PROPERTY[=RHS]}TCODE{else}FCODE{}
Execute TCODE if the string resulting from expanding PROPERTY is equal to STRING. If it's not, execute FCODE.
PROPERTY can be either one of the Package properties specified below, or it can be a variable access. A variable access has the form $VARIABLE. VARIABLE need not be initialized; its content defaults to the empty string.
To change VARIABLE during runtime use this syntax:
{[!]*VARIABLE[=RHS]}
This sets the runtime variable VARIABLE to STRING. With !, the result is either 1 or empty, depending on whether STRING is nonmpty. If the trailing part (including the = sign) is omitted, there is a special meaning: {*I<VARIABLE} sets VARIABLE to 1, {!*I<VARIABLE}> sets VARIABLE to the empty string.
Package properties¶
Names that refer to specific properties of the package that is currently printed. If used to print a property, the name must be enclosed in square brackets (i.e. "<name>").
name, category, homepage, licenses
The name, category, homepage and licenses for the current package.
availableversions:VARIABLE, availableversions:VARIABLE:VARSLOTS
For each version, print the content of the configuration/environment variable with name VARIABLE, interpreting it as a format string. If the second form is used and at least one slot of the package is nontrivial, then VARSLOTS is used instead of VARIABLE, and the versions are sorted according to slots.
To avoid a misunderstanding: It is not possible to enter the required format directly after the colon. Instead, the required format must be stored in a new variable, and VARIABLE and VARSLOTS are only the names of these variables.
Useful examples for VARIABLE are NAMEVERSION, EQNAMEVERSION, EQNAMEVERSION, ANAMESLOT, ANAMEASLOT, NAMESLOT, NAMEASLOT or DATESORT. Here, ANAMESLOT and ANAMEASLOT are meant to be used in the second form, i.e. in availableversions:ANAMESLOT:ANAMESLOT or availableversions:ANAMEASLOT:ANAMEASLOT (Mnemonic: ASLOT prints the slot always). Moreover, NAMESLOT, NAMEASLOT and DATESORT makes sense only for installed versions. See eix --dump to see the variables in detail.
markedversions:VARIABLE, markedversions:VARIABLE:VARSLOTS
This is analogous to availableversions with the difference that only marked versions are printed.
bestversion:VARIABLE, bestversion*:VARIABLE, bestslotversions:VARIABLE, bestslotversions*:VARIABLE, bestslotupgradeversions:VARIABLE, bestslotupgradeversions*:VARIABLE
This is analogous to availableversions with the difference that only the best version resp. the best versions of each slot are printed. For the variants with * also unstable versions are accepted. For the variants with upgrade only those versions are selected which probably will appear after the upgrade.
installedversions:VARIABLE
This is analogous to availableversions with the difference that only installed versions are printed.
installedmarkedversions:VARIABLE
This is analogous to installedversions with the difference that only marked versions are printed.
first, last, slotfirst, slotlast, oneslot
This must occur only in VARIABLE in the context of version printing. You can use these flags to test whether you are currently printing the first or last version of the package (usually to output some additional text in these cases). Similarly, when the printing is sorted according to slots you can test whether the current version is the first or last of the current slot or if there is only one slot at all. All these properties are empty if the condition is not satisfied, otherwise 1. To ease reusing code, when printing is not sorted according to slots, then slotfirst/slotlast is equivalent to first/last and oneslot is 1.
slot, isslot, overlayver, overlaynum, versionkeywords
This must occur only in VARIABLE in the context of version printing. It outputs the current slot, the overlay, or the full keywords of the current version. overlayver is empty if the whole package is from only one overlay; you should use overlay to print the overlay in such a case. overlaynum, in contrast, contains the number of the overlay without colors unconditionally (or is empty if the package is not from an overlay). The output format for versionkeywords depends on FORMAT_BEFORE_KEYWORDS, FORMAT_AFTER_KEYWORDS, B<PRINT_EFFECTIVE_KEYWORDS, FORMAT_BEFORE_EFFECTIVE_KEYWORDS, FORMAT_AFTER_EFFECTIVE_KEYWORDS. isslot just tests whether the slot is trivial and outputs 1 in this case, otherwise nothing.
isbestupgrade, isbestupgrade*, isbestupgradeslot, isbestupgradeslot*
This must occur only in VARIABLE in the context of version printing. It returns 1 if the current version is the best resp. best in the current slot for upgrading. For the variants with * also unstable versions are considered.
installedversion, markedversion
This must occur only in VARIABLE in the context of version printing. It returns 1 or the empty string depending on whether the current version is installed or marked, respectively.
ishardmasked, washardmasked, isprofilemasked, wasprofilemasked, ismasked, wasmasked, isstable, wasstable, isunstable, wasunstable, isalienstable, wasalienstable, isalienunstable, wasalienunstable, ismissingkeyword, wasmissingkeyword, isminuskeyword, wasminuskeyword, isminusunstable, wasminusunstable, isminusasterisk, wasminusasterisk
This must occur only in VARIABLE in the context of version printing. This returns 1 or empty depending whether the version has the current stability property according to the local or default configuration, respectively.
isbinary
This must occur only in VARIABLE in the context of version printing. It returns 1 or empty depending on whether there is a corresponding *.tbz2 file for the version.
restrict, restrictfetch, restrictmirror, restrictprimaryuri, restrictbincheck, restrictstrip, restricttest, restrictuserpriv, restrictinstalledsources, restrictbindist, restrictparallel
This must occur only in VARIABLE in the context of version printing. It returns 1 or empty depending on whether some or the corresponding RESTRICT attribute is set for the version.
properties, propertiesinteractive, propertieslive, propertiesvirtual, propertiesset
This must occur only in VARIABLE in the context of version printing. It returns 1 or empty depending on whether some or the corresponding PROPERTIES attribute is set for the version.
haveuse, use
This must occur only in VARIABLE in the context of version printing. It outputs information corresponding to the IUSE (for available versions) or USE (for installed versions) variables, respectively. haveuse can be used to test whether an output would be nonempty (in this case it is 1 otherwise empty). For available versions, use outputs the IUSE variable. For installed versions, use outputs the USE flags and whether they are installed or not (in the later case, the content of FORMAT_BEFORE_SET_USE, FORMAT_AFTER_SET_USE, FORMAT_BEFORE_UNSET_USE, FORMAT_AFTER_UNSET_USE is printed at the appropriate places).
date:VAR
This must occur only in VARIABLE in the context of version printing. It outputs the installation date; the strftime() format for the date is read from the variable VAR.
version
This must occur only in VARIABLE in the context of version printing. It outputs the plain version in text form.
installed, best, best*
Is 1 or empty, depending on whether at least one version of the package is installed or has a best stable or best unstable version.
versionlines
Is 1 or empty, depending on whether the --versionlines flag was passed.
slotsorted
Is 1 or empty, depending on whether the --versionsort flag was passed.
color
Is 1 or empty, depending on whether colors/markers are printed. For instance if the output is redirected to a terminal and no opposite option is used, this will be empty.
setnames, allsetnames
The name of all local sets to which the package belongs, separated by spaces. With allsetnames also the "system" set name is included.
binary
Is 1 or empty, depending on whether at least one version (available or installed) has a corresponding *.tbz2 file. See the remarks for --binary.
overlaykey
If all versions are in the same overlay, "[overlaykey]" is output with corresponding colors.
system
expands to 1 if the package is in the system profile or provides such a virtual
world
expands to 1 if the package is in the world file or provides such a virtual
world_sets
expands to 1 if the package is in the world sets or provides such a virtual
systempure
expands to 1 if this package is in the system profile
worldpure
expands to 1 if this package is in the world file
world_setspure
expands to 1 if this package is in world sets
provide
the package PROVIDE string
marked
expands to 1 if the package was passed with the --pipe option. This is mainly only useful in tests.
havemarkedversion
Is 1 or empty, depending on whether at least one available version of the package is marked. Note that it is possible that a package is marked although none of its available versions is marked.
slots, slotted
expands to 1 if there are at least two slots resp. at least one nontrivial slot.
colliuse, havecolliuse
The collected IUSE flags (i.e. their union) of all available versions of the package, separated by spaces. havecolliuse expands to 1 if colliuse is nonempty; this is faster than colliuse.
haveversionuse
In order to save memory and/or disk space, eix can be compiled to not store IUSE flags for every single version. If the current package is read from such a database or eix is compiled to not use this information, this test expands to the empty string, otherwise to 1. Even if this test is negative, you can use use:... in the way described earlier; however, the result will be empty in this case.
havebest, havebest*
Expands to 1 if the package has a best stable/unstable version.
upgrade, upgradeorinstall, downgrade, recommend, recommendorinstall
upgrade expands to 1 if the package is installed and at least one slot can be upgraded (or the best stable version is a new slot and UPDATE_TO_HIGHEST_SLOT is true). The other variables test similarly whether the package can be upgraded or newly installed, should be downgraded, can/should be upgraded/downgraded, or can/should be upgraded/downgraded/installed, respectively. The variable RECOMMEND_LOCAL_MODE determines whether these tests obey LOCAL_PORTAGE_CONFIG.
bestupgrade, bestupgradeorinstall, bestdowngrade, bestrecommend, bestrecommendorinstall
as above with the difference that only the best stable version of the package is taken into account (and not all slots).
better, worse, differ, bestbetter, bestworse, bestdiffer
this can only be used in conditionals in DIFF_FORMAT_CHANGED. better expands to 1 if the new package has a new slot or a better stable version (or the same best stable version but from a different overlay number) for some slot than the old package. worse means analogously that the old package had at least one better slot or a slot which is not available in the new package. differ means that not all best stable slots of the old and new package coincide. The corresponding best* versions have an analogous meaning with the difference that only the best stable version is taken into account (and not all slots). The variable RECOMMEND_LOCAL_MODE determines whether these tests obey LOCAL_PORTAGE_CONFIG.
old..., new...
this can only be used in DIFF_FORMAT_CHANGED. You can prefix any property name with old and new, and the value corresponds to that property, taking the old resp. new data into account. If neither old nor new is specified, the new version is assumed. For example, oldavailableversions:VAR will output the previous available versions (using the variable VAR to determine the output format) while newavailableversions:VAR and availableversions:VAR both will print the available versions of the current (i.e. new) package.
Colors¶
(NAME,BRIGHTNESS;MARKERS)Each of the ",BRIGHTNESS" and ";MARKERS" parts may be omitted.
If BRIGHTNESS is 1, eix prints the corresponding 'light' (bold) color for NAME, or normal color if BRIGHTNESS is 0.
An empty NAME means "default" and in contrast to "none" resets output to default color and no markers.
An empty (or omitted) MARKERS means "none", i.e. no attribute change. Several marker attributes can be specified simultaneously (separate them by ",").
Available colors are: default none black red green yellow blue purple cyan gray
Available marker attributes are: none bold underline blink inverse
Examples:¶
FORMAT='{installed}(yellow,1;underline){else}(yellow,0){}<name>()}\n' eix ...
If the package ... is installed, print the name underlined in bright yellow, else in normal yellow.
FORMAT='<category>/<name><installedversions:INSTFORMAT>\n' INSTFORMAT='{first}:{}<version><date:DATEFORMAT>{!last}\n\t{}' DATEFORMAT='%x' eix autom*
This will print for every autom* package the category name, and if it is installed, it will also print the installed versions and the installation dates. One could have obtained the same result by omitting \t\n{} and writing instead :{else}\t\n{}, since it is of course the same whether \t\n is printed at the end of each version except the last or at the beginning of each version except the first.
FORMAT='{downgrade}%{FORMAT_ALL}{}' eix -I
This will print all installed packages for which there are downgrade recommendations. Note that FORMAT='{downgrade}%{FORMAT}{}' does not work, because this would be a self-referential definition in the delayed substitution: Of course, a variable cannot be defined by an expansion of itself. For this reason, the content of FORMAT and similar variables has become very simple since eix-0.13.4: It is just %{FORMAT_ALL} (and similarly for other variables). So one can easily insert the full definition of the original value of FORMAT (which we have done in the above example).
Note that if you want to have compact output in the above example, you cannot just append the option -c, because appending this option just has the effect that for the format string the variable FORMAT_COMPACT is used instead of FORMAT. So, to have compact output, you should use either
FORMAT_COMPACT='{downgrade}%{FORMAT_ALL_COMPACT}{}' eix -Icor even simpler and with the same effect:
FORMAT='{downgrade}%{FORMAT_ALL_COMPACT}{}' eix -I
FILES¶
/etc/eix-sync.conf¶
This file stores commands and configurations to apply with eix-sync. Comments start with # (all lines are cut at the first #; it is not possible to mask #). Lines can have the following forms and will be executed in the given order before emerge --sync is executed.
Note that the content of the variable EIX_SYNC_CONF is appended to that file. By default, the latter expands to EIX_SYNC_OPTS so that also that variable is appended to that file. Both variables can be used to modify the defaults set in /etc/eix-sync.conf. Be aware that a lot code of these lines is evaluated when eix-sync is execute, so take care about security!
option(s)
Use option(s) as default for eix-sync (in front of all other options). As usual, option(s) must start with "-". option(s) will be evaluated by the shell in the eix-sync script, so take care about security and be sure to quote shell command separators properly!
Name
Call layman -s Name. Note that layman is provided by app-portage/layman to sync overlays.
*
Call layman -S (i.e. overlays are synced with layman).
!command
Evaluate command within the eix-sync shell script (in the same shell). command must exit successfully or eix-sync will stop with an error. (Thus, !layman Name is more or less equivalent to Name.) Close e.g. the command with "; true" if you want that the exit status is ignored.
You can use this feature to unpack e.g. an overlay before calling layman or to apply local fixes after layman was called.
In contrast to earlier eix versions, command does not output anything (use einfo if you want that), and it is not evaluated within a subshell, i.e. you can also modify environment variables or begin/end redirection as you like. The disadvantage is that you can also easily override internal eix-sync variables or functions by accident; if in doubt, put your command in braces (...) to start it in a subshell.
!!command
This is similar to ! command with the difference that command is unconditionally executed, i.e. even if options -d, -u, or -l are used. It is meant to set environment variables for the other programs.
~command
This is only important if eix-sync options -s or -2 are used. In this case, command will be executed before the first call of rsync; the output of command is evaluated within the eix-sync shell. If command or the evaluation of its output are not successful, eix-sync will stop with an error. This can be used to execute e.g. keychain and to return the content of the appropriate ~/.keychain/*-sh file or to return export-commands for the current SSH_AUTH_SOCK and SSH_AGENT_PID. It is also admissible that the output of command is a command which modifies the variables PORTAGE_RSYNC_OPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR, PORTDIR_SERVER, PORTDIR_CLIENT, SERVER, or CLIENT. These variables are filled with defaults when command is called and will later be used for the rsync command(s) with their obvious meaning.
@command
Adds a hook for command; the actual execution of command is postponed until emerge --sync was (successfully) called.
@@command
Adds a hook for command; the actual execution of command is postponed until emerge --sync and the subsequent eix-update was (successfully) called.
Here is a schematic overview of the order of hooks/commands:
!! hooks
cp /var/cache/eix /var/cache/eix.previous
layman calls and ! hooks in order of /etc/eix-sync.conf
~ hooks
emerge --sync
@ hooks
eix-update
@@ hooks
eix-diff /var/cache/eix.previous
Some examples of useful lines in /etc/eix-sync.conf:
-C --ignore-default-opts
Use this line if you have --ask in EMERGE_DEFAULT_OPTS in /etc/make.conf but do not want to get asked for eix-sync.
-r -M
Use this if you use e.g. PORTDIR_CACHE_METHOD=assign, and FEATURES=metadata-transfer is inactive or disabled (the latter is the default in newer portage versions). Depending on your needs you might want to use also -r or -M alone or replace -M by the line
@emerge --regen
to use emerge --regen instead of emerge --metadata.
@egencache --repo=local --update
Update the metadata cache of the overlay with repository name "local" before eix-update is called but after calling emerge --sync. This can make sense if you want to use cache method metadata-flat for that overlay and want to make sure that this metadata cache is up-to-date. The disadvantage is that this egencache command is executed even if "local" was not changed (which is usually the case for local repositories).
!egencache --repo=foo --update
Update the metadata cache of the overlay with repository name "foo"; this makes sense if you had earlier a line foo or a line !command to update foo for updating this repository (by layman or by some other command) and if you want to use cache method metadata-flat for that overlay although the metadata cache is broken or not contained in that repository.
!!exec >/var/log/eix-sync.log ; chown portage: /var/log/eix-sync.log || true
Send the output to a logfile (with correct permissions). The "true" at the end is to force continuing even if the "chown" failed. If you do not want to redirect the output of the final eix-diff, you might want to combine this with
@@exec >/dev/tty
Output the eix-diff stat to the terminal, even if redirection occurred.
@@exit 0
Do not execute eix-diff at all.
!!export FORCE_USECOLORS= ${FORCE_USECOLORS:-true}
Unless FORCE_USECOLORS is set differently in your environment, eix output will be colored even if you use redirection.
~keychain --quiet ~/.ssh/id_rsa ; cat ~/.keychain/ `hostname`-sh
@@eix-remote update * `portageq portdir`/local/layman/eix-caches.tar.bz2 *
(The last argument can also be omitted if you do not want a local copy of the data in the /usr/portage/local/layman directory.)
@eix-remote fetch /var/cache/remote-cache.tbz2
@@eix-remote add /var/cache/remote-cache.tbz2
/etc/eixrc¶
Global configuration file. The variables in ~/.eixrc or from the environment can override the variables set in this file. See ~/.eixrc.
EIXRC¶
If this environment variable is set, its value is used instead of the filename /etc/eixrc to read the configuration data. In this case, the file ~/.eixrc is ignored (but you can of course source it if you want it).
EIX_SYNC_OPTS, EIX_SYNC_CONF, EIX_REMOTE_OPTS, EIX_LAYMAN_OPTS, EIX_TEST_OBSOLETE_OPTS¶
Although these variables are usually set in ~/.eixrc (and are therefore described in the corresponding section), these variables are pointed out here because they are exceptionally security relevant: They (or at least part of them) are evaluated by the shell if you call the scripts with the corresponding name. Thus, be sure that they are not compromised when you call these scripts with root permissions.~/.eixrc¶
Per-user configuration file. The variables in this file can be overridden by environment variables. You can use a shell-like syntax to set the following variables. In particular, you can source other files and you can use auxiliary variables to set other variables.
However, if you use auxiliary variables as usual, you will only see the substituted values with --dump or --dump-defaults and you cannot replace the inserted values e.g. by setting them in the environment.
For this reason, you can refer to variables besides the usual shell-way also in the syntax %{VARIABLE} (the braces here are not optional). This means that the substitution is delayed until all configuration files and environment variables are read, and the substitution will not show up with --dump or --dump-defaults.
This concept is called delayed substitution/reference, and provides also some additional features:
Special symbols for delayed substitution
%{%
This must be used if you need %{ in a variable text (otherwise delayed substitution would take place).
*VARIABLE
If a delayed reference uses a variable name starting with *, this * is replaced by EIX_ or DIFF_, depending on whether it is used from eix/eix-update or from eix-diff. This way you can have different defaults for these programs.
For example, the delayed reference %{*VARIABLE} will insert the expansion of EIX_VARIABLE or DIFF_VARIABLE, respectively.
The \ and * attributes can be combined (order plays no role).
\VARIABLE
If a delayed reference uses a variable name starting with \, all \ or [\n\r\t ] symbols of the (expanded) VARIABLE content are considered as escaped.
In particular, the delayed reference %{\VARIABLE} can be used in string list variables like CACHE_METHOD or EIX_LOCAL_SETS, ensuring that VARIABLE produces at most one entry "as is", even if it should contain spaces or \ characters.
The \ and * attributes can be combined (order plays no role).
Conditional blocks in delayed references
If you want to substitute several variables completely differently, depending on the state of a (Boolean) variable, you can use conditional blocks.
This is somewhat analogous to Conditional Blocks in FORMATSTRING: If the referenced variable expands finally to the Boolean value true (true/1/yes/y/on) (resp. to something nonempty if you preceed VARIABLE with an additional ?) the result is true and the corresponding block of the string is expanded. Conditions can be negated so that the else-part is expanded if the condition is true, and the if-part if the condition is false. The else-part can be also be completely left out. The special variable names *VARIABLE (instead of VARIABLE) can also be used in these conditionals.
%{?VARIABLE}TCODE%{}
Expand TCODE if VARIABLE expands to true.
%{??VARIABLE}TCODE%{}
Expand TCODE if VARIABLE expands to a nonempty string.
%{!VARIABLE}TCODE%{}
Expand TCODE if VARIABLE expands to false.
%{!?VARIABLE}TCODE%{}
Expand TCODE if VARIABLE expands to the empty string.
%{?VARIABLE}TCODE%{else}FCODE%{}
Expand TCODE if VARIABLE expands to true, otherwise FCODE.
%{??VARIABLE}TCODE%{else}FCODE%{}
Expand TCODE if VARIABLE expands to a nonempty string, otherwise FCODE.
%{!VARIABLE}TCODE%{else}FCODE%{}
Expand TCODE if VARIABLE expands to false, otherwise FCODE.
%{!?VARIABLE}TCODE%{else}FCODE%{}
Expand TCODE if VARIABLE expands to the empty string, otherwise FCODE.
A conditional block must occur completely within one variable, i.e. it is not possible to e.g. substitute the %{} symbol from another variable via delayed reference (but in TCODE/FCODE delayed references can be used).
Note that any variables you add for delayed substitution are only output with --dump if they are actually used (i.e. referenced in some of the other variables). If you want to output them anyway, e.g. for comments or easier later change, you can collect references to them in the DUMMY variable.
The following variables do not contain those which are used only in delayed references. To get a full description of the latter (and of the defaults), please use eix --dump.
DUMMY (string)
This variable has no direct influence on the programs, but the content of this variable can be used to collect delayed references to (otherwise unused) variables so that they are printed with --dump or --dump-defaults.
EIX_SYNC_OPTS, EIX_SYNC_CONF (string)
The content of EIX_SYNC_CONF is appended to the file @SYSCONFDIR/eix-sync.conf See the description of that file for details. By default, EIX_SYNC_CONF is a delayed substitution of EIX_SYNC_OPTS so that typically you can also use EIX_SYNC_OPTS with the same purpose. Be aware that if one of these variables is compromised, almost anything can happen if you call eix-sync with root permissions, so be aware of security risks! Quote these variables carefully if you use them!
EIX_REMOTE_OPTS, EIX_LAYMAN_OPTS, EIX_TEST_OBSOLETE_OPTS (string)
The content of this variable is evaluated and used as arguments for the scripts eix-remote, eix-layman, and eix-test-obsolete, respectively. So be sure to quote these variables correctly and be aware of security risks!
EIXRC_SOURCE (string)
This path is prepended to source commands in /etc/eixrc. It is meant to be set in the environment but can also be set in /etc/eixrc. In the latter case, it will override the setting from the environment as soon as it is read until all files are sourced. Note that when this variable takes effect, no delayed substitution is performed yet.
EIX_PREFIX (prefix-string) (prefix-string means that this is a string, but if it has the value '/' it is changed to '')
This is essentially meant to be set in the environment if you want to use a chroot: It is prefixed to the path where /etc/eixrc is searched. If it is unset, the value of the environment variable PORTAGE_CONFIGROOT is prefixed. The default value (typically empty) of this variable is used, if neither is set in the environment.
Moreover, this variable is used for delayed substitution to determine the prefix of a lot of paths in the subsequent variables; see eix --dump to see in detail in which other variables it occurs. In the current default, it influences all paths with the following exceptions:
EPREFIX (prefix-string)
The default value of this variable stems from EIX_PREFIX, appended with a configure-specific default (for prefix-portage). This variable has no meaning on its own, but it is used for delayed substitution to determine the prefix of a lot of paths in the subsequent variables (if their default is not changed); see eix --dump to see in detail in which other variables it occurs. In the current default, it influences all paths with the following exceptions:
/usr/bin/eix-functions.sh
~/.eixrc
cachefile path(s) passed in the commandline
PORTAGE_PROFILE (only the variable, not the link)
PORTDIR
Overlay paths
The last three items can be modified by EPREFIX_TREE.
The purpose of EPREFIX is to allow a quasi-chroot analogously to prefix-portage. Note that as a prefix-portage user you will want to use option -e in eix-sync.
ROOT (prefix-string)
EPREFIX_TREE (prefix-string)
EPREFIX_ROOT (prefix-string)
These are actually not internal variables of eix but they are just used for delayed substitution for the following variables analogously to EPREFIX (see above).
The purpose of ROOT is to follow roughly portage's usage of this variable. Note that variables in /etc/make.conf do not influence eix configuration variables. In particular, a ROOT=something command in /etc/make.conf does not influence eix. You must set it instead in the environment or in an eix configuration file.
You can easily customize to which paths the EPREFIX or ROOT variables apply: Simply use in the appropriate following variables either the delayed references %{EPREFIX}, %{ROOT}, nothing, or %{EPREFIX_ROOT} (which in turn is defined as a delayed reference so that you can easily change what to do if EPREFIX and ROOT are both nonempty: You might e.g. concatenate these paths or use only one of them). You can of course also use other variables as delayed references, e.g. you might want to set
EIX_CACHEFILE= %{EPREFIX_PROFILE}/var/cache/eix
if you feel that the eix cachefile should depend (only) on the profile root.
PORTAGE_CONFIGROOT (prefix-string)
This path is prepended to the /etc paths. The purpose is to respect PORTAGE_CONFIGROOT in an analogous way portage does. If you set this variable in the environment it will also change the path where /etc/eixrc is searched. (Note that reading /etc/eixrc occurs before delayed substitution takes effect.)
MAKE_GLOBALS (string)
If this file exists, it is used instead of %{PORTAGE_CONFIGROOT}/etc/make.globals The default value corresponds to >=portage-2.2* behavior.
EPREFIX_SOURCE (prefix-string)
This path is prepended to paths occurring as the argument of source commands in /etc/make.conf and /etc/make.globals.
EPREFIX_INSTALLED (prefix-string)
This is prepended to the path where eix expects information about installed packages.
EPREFIX_PORTAGE_CACHE (prefix-string)
This prefix is prepended to the portage cache.
EPREFIX_ACCESS_OVERLAYS (prefix-string)
This prefix is prepended to overlays when their files are accessed.
EPREFIX_PORTDIR (prefix-string)
This path is prepended to PORTDIR.
EPREFIX_OVERLAYS (prefix-string)
This prefix is prepended to all entries of PORTAGE_OVERLAY.
EPREFIX_PROFILE (prefix-string)
This prefix is prepended to PORTAGE_PROFILE (the variable, not the link).
EPREFIX_VIRTUAL (prefix-string)
This is prepended to overlays in the eix database to test whether they exist.
EIX_CACHEFILE (string)
The eix cachefile (usually %{EPREFIX}/var/cache/eix).
EIX_WORLD (string)
The file eix considers as the world file. Note that usually this file is only readable if you are a member of the portage group. To avoid needing this permissions you can use SAVE_WORLD.
EIX_WORLD_SETS (string)
The file eix considers as the world_sets file. The same remarks as for EIX_WORLD hold true.
EIX_LOCAL_SETS (string list)(the meaning of string list is explained in the next paragraph)
This is a list of directories which contain locally defined sets. The directories are read in the given order; files with set-names which have been read earlier are ignored: In this sense earlier entries in EIX_LOCAL_SETS take precedence over later entries.
Relative directories (i.e. those not starting with /) are understood relative to $PORTDIR. Entries in EIX_LOCAL_SETS starting with the special symbol * are interpreted in a special way: They are interpreted as several entries, the * symbol being replaced successively by the paths to the overlays in reverse order (the latter in view of the fact that in a sense earlier entries of EIX_LOCAL_SETS override later entries while for PORTDIR_OVERLAY one expects the converse).
The default of this variable contains /etc/portage/sets, /etc/portage/sets.eix, sets (i.e. roughly ${PORTDIR}/sets according to the previous paragraph), */sets (i.e. roughly ${PORTIDR_OVERLAY}/sets according to the previous paragraph) as well as %{EIX_LOCAL_SETS_ADD}. The reason for the latter is that you can just add additional directories to the variable %{EIX_LOCAL_SETS_ADD} in /etc/eixrc. Reasons why you might want to do this is e.g. if you defined another multiset directory (e.g. for some overlay or for treatment with "world-candidate = False") in /etc/portage/sets.conf or in the sets.conf file of some overlay.
For all string list variables, the possible separators between different entries are [ \t\r\n]. If you want to use such a separator within an entry, you have to escape it by \. Moreover, all \ symbols have to be escaped analogously, since the escapes of escapes and escapes of the separator symbols are removed. If you want to insert a variable "as-is", you can make use of delayed substitution: %{\VAR} will insert the value of VAR with all symbols from [\ \t\r\n] being escaped. (See delayed substitution for more details).
EAPI_REGEX
This regular expression matches the recognized EAPIs in .ebuild suffixes which will be recognized according to GLEP 55. You might need to modify this expression locally according to the installed portage version (in order to make sure that the installed portage can parse the corresponding EAPIs). An exceptional case is if that variable is empty: In this case all EAPI-suffixed ebuilds are ignored.
SAVE_WORLD (true/false)
If you set this to true, the information of your world file is stored in /var/cache/eix. Note that this means that anybody who can read this file has the information about the content of your world file. Make sure that this is really what you want if you set this to true.
CURRENT_WORLD (true/false)
If false, then the world file information stored in /var/cache/eix is used, even if your current world file is readable. Otherwise, your current world file (if it is readable) overrides that information.
SKIP_PERMISSION_TESTS (true/false)
If true, eix-update will not check for groups and permissions. You will probably want to set this to true if you have a more sophisticated permission setup on your system (NSS/LDAP, acl, pam-related stuff, ...) in which case eix might guess wrong permissions. The only negative side effect is that eix-update does not break with an error at the beginning but will stop with a (perhaps misleading) error message when trying to access the cache file without proper permissions.
EBUILD_USER, EBUILD_GROUP, EBUILD_UID, EBUILD_GID
These variables determine the permissions for cache methods ebuild/ebuild*. See these cache methods for more details
PORTAGE_ROOTPATH, PORTAGE_BIN_PATH
If nonempty, these variables are passed unchanged to ebuild.sh for cache method ebuild*. Note that ebuild.sh uses these variables to calculate the PATH, so this may be a severe security issue.
NOFOUND_STATUS (integer)
This value is used as exit status if there are 0 matches. The value of COUNT_ONLY_PRINTED is honoured.
MOREFOUND_STATUS (integer)
This value is used as exit status if there are 2 or more matches. The value of COUNT_ONLY_PRINTED is honoured.
QUICKMODE (true/false)
If true, eix and eix-diff will use --quick by default.
CAREMODE (true/false)
If true, eix and eix-diff will use --care.
USE_BUILD_TIME (true/false)
Whether to use the BUILD_TIME entry (if it exists) of the portage database instead of the directory timestamp (which usually is the installation time). The difference is usually only important for packages installed from .tbz2, but in most cases the build time is more relevant (it is also more reliable). Unfortunately, the build time is available only for packages built and emerged with >=portage-2.2_rc63; you can use eix-installed [no-]buildtime to check for which versions this is (not) the case. Reading the build time is always slower than using the directory timestamp (even if the build time is not available). Thus, you might want to set this variable to false if speed of eix is more important to you than the buildtime information.
QUIETMODE (true/false)
If true, eix and eix-diff will use --quiet by default.
PRINT_APPEND (string)
This string is appended to the output of --print. Standard escape sequences in this string like \n are interpreted. The default is a newline for reasonable output in an interactive shell. Note that command substitution in shell scripts removes all trailing spaces so that this newline does not harm (but trailing spaces of the variable would be removed in the shell script anyway). Hence, in order to read variables from eix in a shell script without omitting trailing spaces, you should use a visible symbol for PRINT_APPEND and use for instance something like VAR="`PRINT_APPEND=x eix --print VAR`" ; VAR="${VAR%x}"
NEWLINE (true/false)
If true, eix will print a newline after each version for which the formatstring outputs something. You will find true convenient if you use trivial formatstrings which output only one line (unless you want to add the newline manually to the formatstring). However, if you use a formatstring which outputs versions in separate lines, and only those versions are output for which certain tests succeed, it might be rather cumbersome to keep track in the formatstring whether you must output a newline or whether this will happen automatically. In such cases you should should avoid the headache and put NEWLINE=false. The default formatstrings of eix produce correct output for both settings (by checking the value of NEWLINE and outputting the newline only if it is required).
Unless you need to support formatstring which you had previously written, I recommend to leave the default NEWLINE=false and to add manually a \n (or an explicit newline) at the end of your formatstring. Moreover, if you had written formatstrings, I recommend to upgrade them to output this newline instead of setting NEWLINE=true; this option really just exists for backward compatibility and might be removed in future versions of eix.
DEFAULT_FORMAT (normal/compact/verbose)
Defines whether --compact or --verbose is on by default.
DIFF_ONLY_INSTALLED (true/false)
If true, eix-diff will only consider version changes for installed packages.
DIFF_NO_SLOTS (true/false)
If true, eix-diff will not consider slots for version changes.
DIFF_SEPARATE_DELETED (true/false)
If true, eix-diff will print deleted packages in a section on their own. Otherwise, eix-diff will mix deleted and changed packages "alphabetically".
DIFF_PRINT_HEADER (true/false)
If true, eix-diff will print a header info line.
NO_RESTRICTIONS (true/false)
If false, RESTRICTION and PROPERTIES data is output.
RESTRICT_INSTALLED (true/false)
If true, fetch and mirror restrictions for installed versions are calculated.
CARE_RESTRICT_INSTALLED (true/false)
If true, fetch and mirror restrictions for installed versions are always fetched from disk, even if it could be read from a corresponding version. This is slower but more reliable, i.e. it will also find out whether restrictions were changed.
FORMAT, FORMAT_COMPACT, FORMAT_VERBOSE (string)
Define the normal, compact and verbose layout for results printed by eix. See FORMATSTRING. Since eix-0.13.4 these variables just expand to delayed substitution of the variables FORMAT_ALL, FORMAT_ALL_COMPACT, or FORMAT_ALL_VERBOSE, respectively. The intention of this simple definition is that it is very easy to refer to the default definition when you change the definition of FORMAT.
DIFF_FORMAT_NEW, DIFF_FORMAT_DELETE, DIFF_FORMAT_CHANGED (string)
Define the format for packages that were added, removed or for which the highest stable versions has changed. This is only used by eix-diff. See FORMATSTRING. Since eix-0.13.4 these variables just expand to delayed substitution of the variables DIFF_FORMAT_ALL_NEW, DIFF_FORMAT_ALL_DELETE, or DIFF_FORMAT_ALL_CHANGED, respectively.
FORMAT_INSTALLATION_DATE, FORMAT_SHORT_INSTALLATION_DATE
Define the strftime() format used to print the installation date (in normal resp. short form).
FORMAT_INSTALLED_USE
Define the printf-like format used to print useflags of installed packages. If this string is empty, the processing is slightly faster since then these data are not read.
FORMAT_BEFORE_KEYWORDS, FORMAT_AFTER_KEYWORDS, FORMAT_BEFORE_EFFECTIVE_KEYWORDS, FORMAT_AFTER_EFFECTIVE_KEYWORDS
These strings are printed before/after the (effective) KEYWORDS string for a version is printed.
FORMAT_BEFORE_SET_USE, FORMAT_AFTER_SET_USE, FORMAT_BEFORE_UNSET_USE, FORMAT_AFTER_UNSET_USE
These strings are printed before/after the set/unset USE flags of installed versions are printed.
FORCE_USECOLORS (true/false)
Use colors even when stdout is not a terminal.
FORCE_PERCENTAGE (true/false)
Show the percentage progress even when stdout is not a terminal.
STYLE_VERSION_SORTED (true/false)
Defines whether --versionsort is on by default.
STYLE_VERSION_LINES (true/false)
Defines whether --versionlines is on by default.
DUP_PACKAGES_ONLY_OVERLAYS (true/false)
Defines whether duplicate package checks occur only among overlays, i.e. a package is only considered as duplicate if it occurs in at least two different overlays.
DUP_VERSIONS_ONLY_OVERLAYS (true/false)
Defines whether duplicate version checks occur only among overlays, i.e. a version is only considered as duplicate if it occurs at least twice in overlays.
DEFAULT_IS_OR (true/false)
If several pattern arguments occur without logical concatenation (-a or -o), eix assumes an implicit concatenation. If this variable is true, it assumes that this concatenation is -o (or), otherwise -a (and).
OVERLAYS_LIST (all/all-if-used/all-used/all-used-renumbered/no)
People with many different overlays do not want to see all overlays listed at the end but only those which are really used. Here, you can customize the behaviour. The value is interpreted as follows:
all-if-used/if-used/if
Display all overlays, if at least one is used. This was the default behaviour before eix-0.6.0.
used-renumbered/renumber/renumbered/number
Display only the overlays actually used, numbering them "correctly" (i.e. if only two overlays are needed, number them [1] and [2]). The disadvantage is that overlays get different numbers for different queries. However, the order of the numbering is consistent.
all-used/only-used/used
Display only the overlays actually used, keeping the numbering consistent over all queries (on the same database).
no/false
Never display a list of overlays.
anything else
List all overlays for every query (even if not even one is needed).
LEVENSHTEIN_DISTANCE (integer)
Set default levenshtein-distance.
EXCLUDE_OVERLAY (string list)
Set a list of wildcard patterns for overlay paths that are excluded from the index. See the eix-update option --exclude-overlay.
ADD_OVERLAY (string list)
Set a list of overlays that are added to the index. See the eix-update option --add-overlay.
EXPORT_PORTDIR_OVERLAY (true/false)
If true and overlays are excluded/added, a correspondingly modified PORTDIR_OVERLAY is exported. This means that in a sense also the corresponding eclasses of these overlay are excluded/added for cache methods eix and eix*.
CACHE_METHOD_PARSE (string)
This string is appended to all cache methods using parse/parse*/ebuild/ebuild*. Its default contains #metadata-flat. Unless you have a very special setup this is always what you want: It means that if current metadata is available for the ebuild, this is used instead of parsing/executing the ebuild. The latter is in principle not completely reliable (parsing) or rather slow (executing), i.e. the metadata (if available and up-to-date) is always preferable.
PORTDIR_CACHE_METHOD, OVERLAY_CACHE_METHOD (string)
Set the type of the cache used by portage and for overlays. PORTDIR_CACHE_METHOD defaults to metadata-flat, OVERLAY_CACHE_METHOD to parse|ebuild*.
Security Warning: If you do not completely trust the .ebuilds in your overlays, you should set OVERLAY_CACHE_METHOD=parse.
You might want to set temporarily OVERLAY_CACHE_METHOD=eix*::~ - as will be explained later, eix will then take by default the overlay data from the previous eix database.
The available cache methods are described below. You might want to specify a different cache method only for some overlays. This can be done with the following variables:
CACHE_METHOD, OVERRIDE_CACHE_METHOD (string list)
These variables are string lists of the form "overlay method overlay method ...". The cache method of overlay is set to the subsequent method, thus overriding the default settings of OVERLAY_CACHE_METHOD (or of PORTDIR_CACHE_METHOD if overlay is the PORTDIR directory). overlay is interpreted as a wildcard pattern which should match the path (symbolic links resolved) of the overlay (it is not possible to refer to repository's name here - you must use the true path). Later entries override earlier ones: The last matching entry takes precedence.
The difference between CACHE_METHOD and OVERRIDE_CACHE_METHOD is that the former applies immediately while the latter can also be used to extend/override the changes made implicitly if KEEP_VIRTUALS is used (see below).
The default definitions of CACHE_METHOD and OVERRIDE_CACHE_METHOD contain %{ADD_CACHE_METHOD} and %{ADD_OVERRIDE_CACHE_METHOD}, respectively. According to the mechanism of delayed substitution explained in another section, this means that the variables ADD_CACHE_METHOD or ADD_OVERRIDE_CACHE_METHOD can also be used to override the cache method locally. If you modify CACHE_METHOD or OVERRIDE_CACHE_METHOD in /etc/eixrc, it is recommended to add " %{ADD_CACHE_METHOD}" or " %{ADD_OVERRIDE_CACHE_METHOD}" (note the space in front of %) at the end of the respective modified definitions, so that these variables can still be used for local overriding.
The following cache methods are available:
metadata-flat or metadata-flat:PATH
Use the metadata-cache located inside the portage-tree ($PORTDIR/metadata/cache). This is the default method which will always work if the portage tree is readable when you run eix-update.
If you provide PATH, it overrides the above path; in this case, it must be the full path (i.e. no prefix is used). You might want to provide PATH if you use some package manager to generate the metadata in the corresponding directory.
metadata-assign or metadata-assign:PATH
This is similar to metadata-flat with the difference that the files within the metadata cache are expected to be in an "assignment format" (TYPE=value) which is the case in some alt-gentoo trees.
sqlite
This is an extremely fast cache method if you are using portage with the sqlite backend, see (originally this was described in which might be still accessible at ). Note that in contrast to the default metadata cache method you must use emerge --metadata before you call eix-update with this method.
Since the support of this cache method requires sqlite to be installed, this method is not necessarily compiled in. You must have emerged eix with the appropriate USE flag (or in a manual installation used ./configure --with-sqlite before compilation) if you want support for this method.
As for all other cache methods, only those categories enabled by profile/category (in the main tree or some overlay) are read. If you do not want this, use sqlite* (see below).
sqlite*
This is analogous to the cache method eix with the difference that all categories found in FILE are added, even those categories which were not enabled by some profile/categories file.
cdb
Use this if you are using <portage-2.1 and the cdb-module from as cache-backend for portage (cdb with cpickle'd dictionaries as values). Note that in contrast to the default metadata-* cache methods you must use emerge --metadata before you call eix-update with this method.
flat or flat:PATH
This is similar to metadata-flat with the difference that the metadata is expected in the directory PATH_${PORTAGE_OR_OVERLAY_DIR}. If _PATH is omitted, it defaults to /var/cache/edb/dep.
You can use this cache method with <portage-2.1 and the default backend.
assign or assign:PATH
This is analogous to flat with the difference that the files are expected to be in an "assignment format" (TYPE=value). This is the case if you use portage-2.1 with the default backend.
If you are using >=portage-2.1 and the default backend, you might want to use this one if you do not have access to the portage tree when you run eix-update. Note that in contrast to the default metadata-* cache methods you must run emerge --metadata before you call eix-update with this method. You will probably want to use a corresponding option in eix-sync in this case.
repo-flat or repo-flat:PATH or repo-assign or repo-assign:PATH
This is analogous to flat/assign with the difference that the metadata is expected in the directory PATH/${repo_name}. If ${repo_name} is empty, the name x-XXX is assumed where XXX is the last nonzero path component of the portage/overlay directory. This corresponds to the naming scheme of paludis. If this gives a wrong path for some overlay, you can still manually override this with e.g. OVERRIDE_CACHE_METHOD='bad_overlay metadata-assign:correct_path'.
parse[#metadata-method]...
Get the information from the ebuilds, parsing it using some heuristics. Hence, this method has no security risk but possibly some other problems. For example, if variables are only set in eclasses, this method will not see them. Examples of problems with this method is missing SLOT information for typical ebuilds from kde-base or stupid version numbers for gcc cross-compilers. This is the cache-method none from older eix versions (before 0.11.1).
It is optionally possible to append one or several strings of the form #metadata-method where metadata-method is any of the above mentioned cache methods (excluding sqlite and cdb). In this case, the metadata-methods are used to check whether they contain newer information than the ebuild. If this is the case, the metadata is used instead of the ebuild (the first matching metadata wins).
Usually this is what you want, especially for overlays, since the metadata is more reliable than the results of cache method parse. Of course, this is only useful if the overlay foo contains metadata which is regularly updated by the overlay maintainer using
egencache --repo=foo --update
(whether this is done for layman overlays depends on the overlay maintainer; for your local overlays you can of course use the above command manually).
Since this is usually what you want, the string in CACHE_METHOD_PARSE is appended by default to the cache method parse.
Of course, if you know in advance that the metadata information of the overlay is up-to-date, it is (slightly) faster to use directly to use the corresponding metadata method (usually metadata-flat). The latter makes sense if you e.g. call egencache from a script which you use to sync the overlay (e.g. in eix-sync).
parse*[#metadata-method]...
This is essentially the same as cache method parse with the difference that variables are not expanded in variable definitions. This is the cache-method none* from older eix versions (before 0.11.1) and cache-method none from very old eix versions (before 0.7.1)
ebuild[#metadata-method]...
If no portage cache is available (e.g. for overlays) this is the most compatible but also the slowest method. The information is obtained via "/usr/bin/ebuild ... depend" from the ebuild. Since all ebuilds will get executed by bash, this may be a security risk if you do not trust all ".ebuild" scripts or your environment variables. eix-update will attempt to change the user/group to EBUILD_USER/EBUILD_GROUP (using EBUILD_UID/EBUILD_GID if the former makes no sense) before executing the ebuild. Intentionally, the environment is not cleared before the actual execution so that you can pass further variables to the ebuild. However, this can also lead to unexpected behaviour or even a security risk since many bash scripts may be tricked with strange environments. Use env -i eix-update when this causes problems.
Do not use this method if you do not completely trust all .ebuilds for which the method applies!
Concerning the optional appendices #metadata-method, see the description of the cache method parse. Note that if corresponding metadata is available this will be essentially faster than executing the ebuild.
ebuild*[#metadata-method]...
This is a slightly faster and slightly less compatible version of ebuild: The information is obtained via the undocumented "/usr/lib/portage/ebuild.sh". Thus, instead of executing a python program for each ".ebuild" as for cache-method ebuild, "only" a lengthy shell-script and the ebuild itself is executed (hence, also this method is unsafe if you do not trust all ".ebuild" scripts). Most environment variables except for portage variables and PATH are cleared; PORTAGE_BIN_PATH and PORTAGE_ROOTPATH are exported (be aware that ebuild.sh uses these to calculate the PATH, so this may be a severe security issue); some .ebuild-specific variables like $P are set when the ebuild is executed. This method is not quite as compatible as the method ebuild, and its success may depend more on the portage version. However, this method is considerably faster than ebuild and stable enough to treat e.g. typical ebuilds from kde-base.
Do not use this method if you do not completely trust all .ebuilds for which the method applies!
parse|ebuild, parse*|ebuild, parse|ebuild*, parse*|ebuild* [#metadata-method]...
This is a mixture of parse/parse* and ebuild/ebuild*. Each ebuild is first scanned as with method parse/parse*. If the obtained result has missing information or appears strange, the ebuild is treated as with cache method ebuild/ebuild*. As a rule of thumb, this method is much faster than ebuild/ebuild* but still much slower than parse/parse*. It has the same security risks as ebuild/ebuild*, of course.
Do not use this method if you do not completely trust all .ebuilds for which the method applies!
eix or eix:FILE or eix:FILE:overlay
Use the cachefile FILE previously generated by eix-update. If omitted or empty, FILE defaults to /var/cache/eix.
As for all other cache methods, only those categories enabled by profile/category (in the main tree or some overlay) are read. If you do not want this, use eix* (see below).
If overlay is not given or empty, then only the "main" tree in FILE is read - overlays within FILE are ignored. Otherwise only the part corresponding to overlay is read from FILE. Here, "corresponding" means the first overlay from FILE matching the wildcard pattern overlay is used. "Matching" means that first the label is tested, then the path and finally also the number of the overlay within FILE. Note that overlay has in general no relation with the current overlay names or order - only the names/order stored in FILE play a role here.
There are two exceptional values for overlay which are treated by different rules:
If overlay has the special value "~", then the name of the current overlay label is used implicitly as the overlay argument; If the current overlay label is empty or does not match, then the current overlay path is used instead.
If overlay has the special value "*", then all overlays in FILE are read. Note this is usually not what you want since it means that if FILE originally contained several overlays, this overlay structure will appear "flattened".
eix* or eix*:FILE or eix*:FILE:overlay
This is analogous to the cache method eix with the difference that all categories found in FILE are added, even those categories which were not enabled by some profile/categories file.
This cache method is useful if FILE contains information for some overlay directory for which the corresponding profile/categories on the local machine is unknown or not necessarily up-to-date.
This is used for eix-remote.
Note that in particular with PORTDIR_CACHE_METHOD="eix*::~", the overlay data is by default just "copied" from the previous eix cachefile.
KEEP_VIRTUALS (true/false)
If true, eix-update will keep all virtual overlays from the previous database if that existed. This has the same effect as appending for each virtual overlay of the previous database the entry "overlay-name" to ADD_OVERLAY and appending a corresponding entry "overlay eix*::overlay" to CACHE_METHOD. Note that this means that this option might override settings made in CACHE_METHOD, but it might be overridden by settings from OVERRIDE_CACHE_METHOD.
REPO_NAMES
This variables is a string list of the form "dir-pattern overlay-label dir-pattern overlay-label ...". When a new cachefile is created, the overlay matching dir-pattern obtains the label overlay-label, independent of the content of its profiles/repo_name file. This variable can also associate label names to virtual overlays which do not possess such a file. In particular, this variable also overrides overlay labels set by KEEP_VIRTUALS. Later entries override earlier ones: The last matching entry takes precedence.
LOCAL_PORTAGE_CONFIG (true/false)
If false, /etc/portage and ACCEPT_KEYWORDS (from make.conf or the environment) are ignored. Since eix-0.7.9, it is recommended to leave this value "true", because setting it to "false" will just hide some informations.
ALWAYS_ACCEPT_KEYWORDS (true/false)
If true, ACCEPT_KEYWORDS is used even without LOCAL_PORTAGE_CONFIG, e.g. to determine the `default' stability.
UPGRADE_LOCAL_MODE (+ or local/- or non-local/anything else)
If this variable is + / -, the --upgrade option of eix will always match as if LOCAL_PORTAGE_CONFIG was set to true / false.
RECOMMEND_LOCAL_MODE (+ or local/- or non-local/anything else)
If this variable is + / - the upgrade/downgrade recommendations as well as in eix-diff the tests for version changes will act as is LOCAL_PORTAGE_CONFIG was set to true / false.
UPGRADE_TO_HIGHEST_SLOT (true/false)
If true, all upgrade tests will give a positive result for an installed package for which not the slot with the best stable version is installed. Exceptions to this general policy can be specified in /etc/portage/package.slot_upgrade_forbid or /etc/portage/package.slot_upgrade_allow, respectively.
RECURSIVE_SETS (true/false)
If true, then sets and packages which are contained in an included set are considered as part of the parent set.
PRINT_EFFECTIVE_KEYWORDS (true/false)
If PRINT_KEYWORDS is in effect and this variable is true and the KEYWORD of a version is modified by the profile, then the effective keywords (according to the profile) is printed after the KEYWORDS stored in the ebuild.
XML_KEYWORDS(full/effective/both/true/full*/effective*/none/false)
With --xml, this variable decides whether full/effective (or both) types of KEYWORDS are printed for each versions. Here, "full" is the KEYWORDS string as specified in the ebuild and "effective" means its modification by the profile. The values full*/effective* are similar to full/effective, but both types are printed if their values differ. true/false are equivalent to full*/none.
XML_OVERLAY (true/false)
With --xml, this variable decides whether the overlay (i.e. its path) is output for each version. This has no influence for versions from overlays without label (repository name): For those versions the overlay is output unconditionally.
SORT_INST_USE_ALPHA (true/false)
If true, print the useflags of installed packages in alphabetical order. Otherwise, first those useflags are printed (in alphabetical order) which were set when the package was emerged, then the others are printed (in alphabetical order).
CHECK_INSTALLED_OVERLAYS (true/false/repository)
If true, always check from which overlay a package was installed. If false, only packages with versions in at least two trees are checked, i.e. only packages for which it appears reasonable from the database that it might have been installed from a different overlay. However, this information might be false if such a package was removed from an overlay or if a whole overlay is not in the database anymore.
The special value repository is a reasonable compromise: If repository data was stored during emerge (this is the case only with current portage versions; you can use eix-installed [no-]repository to check for which versions this is (not) the case) then this repository data is always used. Only if it is unreadable or does not match, the behaviour for that version is the same as in case CHECK_INSTALLED_OVERLAYS=false.
Especially in connection with option -T (if NONEXISTENT_IF_OTHER_OVERLAY is true) and with option -J the speed increase is enormously if you set this variable to false or repository, but you should be aware that the information used about the installed overlay is not completely reliable (for versions installed with old portage versions). In particular, the option -T will not detect if an installed version of a package actually stems from a redundant overlay if in the current database all versions of this package stem from one (other) location.
OBSOLETE_MINUSASTERISK (true/false)
If true, treat -* in /etc/portage/package.keywords as portage-2.1.2 and earlier versions do. Since portage-2.1.2, the -* keyword is practically obsolete and was replaced by ** which accepts anything (even an ebuild with empty KEYWORDS). Note that there are also the related keywords * and ~* which accept stable or unstable versions of any arch listed in KEYWORDS.
PRINT_COUNT_ALWAYS (true/false/never)
If true, always print the number of matches in the last line, even if this number is 0 or 1. If PRINT_COUNT_ALWAYS=never, then this last line is omitted completely. Both is normally not useful but might simplify writing certain scripts parsing the output of eix.
COUNT_ONLY_PRINTED (true/false)
If false, print only the number of matches, independently of whether the matches actually lead to some output. This might be useful for certain scripts if you are only interested in the number of matches and use e.g. FORMAT='' to speed things up.
DEFAULT_MATCH_FIELD (string list)
This is a list of strings of the form regular_expression[\n\r\t ]match_field which is used to determine the default match field. The search pattern from the command line is matched against all the regular_expression values in this list in the given order. For the first match, the corresponding match_field value is used as the default match field. You can specify a last match_field (without a regular_expression) in this list which is used as the default fallback if all matches failed; if there is no such entry, then name is assumed. It may be convenient to use delayed substitution ${\VAR} for regular_expression to avoid manually inserting additional escapes.
The possible values for match_field are name, category, category/name (or category-name), description, license, homepage, provide, virtual, set, slot, installed-slot, use (or iuse), with-use (or installed-with-use), without-use (or installed-without-use), corresponding to the analogous command line option for the match field. The special value virtual selects simultaneously the two command line options -A and -P.
DEFAULT_MATCH_ALGORITHM (string list)
This is a list of strings of the form regular_expression[\n\r\t ]match_algorithm which is used to determine the default match algorithm. This is analogous to DEFAULT_MATCH_FIELD with the only difference that match_algorithm specifies the default match algorithm chosen. The possible values for match_algorithm are regex, pattern, substring, begin, end, exact, fuzzy which correspond to the analogous command line option for the match algorithm. If no other default match algorithm default is specified, then regex is used.
TEST_FOR_EMPTY (true/false)
Defines whether empty entries in /etc/portage/package.* are shown with -t.
TEST_KEYWORDS (true/false)
Defines whether /etc/portage/package.keywords is tested with -t.
TEST_MASK (true/false)
Defines whether /etc/portage/package.mask is tested with -t.
TEST_UNMASK (true/false)
Defines whether /etc/portage/package.unmask is tested with -t.
TEST_USE (true/false)
Defines whether /etc/portage/package.use is tested with -t.
TEST_ENV (true/false)
Defines whether /etc/portage/package.env is tested with -t.
TEST_CFLAGS (true/false)
Defines whether /etc/portage/package.cflags is tested with -t.
TEST_REMOVED (true/false)
Defines whether removed packages are tested with -t.
TEST_FOR_NONEXISTENT (true/false)
Defines whether non-existing installed versions are positive for -T. What is considered as non-existent is defined by the NONEXISTENT_IF-variables.
TEST_FOR_REDUNDANCY (true/false)
Defines whether redundant entries in /etc/portage/package.* are positive for -T. What is considered as redundant is defined by the REDUNDANT_IF-variables.
ACCEPT_KEYWORDS_AS_ARCH (full/true/false)
If full or true modify ARCH by ACCEPT_KEYWORDS. This determines which keywords are considered as ARCH or OTHERARCH. The value full also influences the original ARCH keywording.
NONEXISTENT_IF_OTHER_OVERLAY (true/false)
Defines whether versions are non-existent for TEST_FOR_NONEXISTENT if they come from a different overlay than the installed version.
NONEXISTENT_IF_MASKED (true/false)
Defines whether masked versions are non-existent for TEST_FOR_NONEXISTENT.
REDUNDANT_IF_DOUBLE (string)
Applies if /etc/portage/package.keywords lists the same keyword twice for some/all (un-/installed) versions.
string describes which versions should be tested. It can have the following values:
no or false
Do not test for this type of redundancy.
some
It suffices that the redundancy occurs for some version in the database.
all
The redundancy must occur for all versions in the database.
some-installed
It suffices that the redundancy occurs for some installed version. Uninstalled versions are ignored for this test.
all-installed
The redundancy must occurs at least for all installed versions of the package. If no version is installed, it must occur at least once.
some-uninstalled
It suffices that the redundancy occurs for some uninstalled version. Installed versions are ignored for this test.
all-uninstalled
The redundancy must occurs at least for all uninstalled versions. If all versions in the database are installed, it must occur at least once.
-some of the above or +some of the above
The test only applies if in addition no version (in case -) resp. at least some version (in case +) of the package is installed.
some of the above or some of the above
The result is positive if at least one of the two tests is positive. Instead of "or" also the symbols "|" or "||" can be used.
REDUNDANT_IF_DOUBLE_LINE (string)
Applies if /etc/portage/package.keywords has two lines for identical targets, i.e. such that portage would drop the first of these lines. Note that lines with targets foo/bar and =foo/bar-1 are considered as different in this context by portage (and thus also by eix) even if foo/bar would apply to version 1. The latter redundancy can be found implicitly with REDUNDANT_IF_DOUBLE_LINE, REDUNDANT_IF_MIXED, and REDUNDANT_IF_STRANGE.
REDUNDANT_IF_MIXED (string, see above)
Applies if /etc/portage/package.keywords lists two different keywords, e.g. ~ARCH and -*, for the versions in question.
REDUNDANT_IF_WEAKER (string, see above)
Applies if /etc/portage/package.keywords lists a keywords which can be replaced by a weaker keyword, e.g. -* or ~OTHERARCH or OTHERARCH in place of ~ARCH, or ~OTHERARCH in place of OTHERARCH, for the versions in question.
REDUNDANT_IF_STRANGE (string, see above)
Applies if /etc/portage/package.keywords lists a strange keyword, e.g. UNKNOWNARCH (unknown to the .ebuild and ARCH) or -OTHERARCH, for the versions in question.
REDUNDANT_IF_MINUSASTERISK (string, see above)
Applies if /etc/portage/package.keywords contains some -* entry. This test only applies if OBSOLETE_MINUSASTERISK is false.
REDUNDANT_IF_NO_CHANGE (string, see above)
Applies if /etc/portage/package.keywords provides keywords which do not change the availability keywords status for the versions in question.
REDUNDANT_IF_MASK_NO_CHANGE (string, see above)
Applies if /etc/portage/package.mask contains entries which do not change the mask status for the versions in question.
REDUNDANT_IF_UNMASK_NO_CHANGE (string, see above)
Applies if /etc/portage/package.unmask contains entries which do not change the mask status for the versions in question.
REDUNDANT_IF_DOUBLE_MASKED (string, see above)
Applies if /etc/portage/package.mask matches twice for the versions in question.
REDUNDANT_IF_DOUBLE_UNMASKED (string, see above)
Applies if /etc/portage/package.unmask matches twice for the versions in question.
REDUNDANT_IF_DOUBLE_USE (string, see above)
Applies if /etc/portage/package.use matches twice for the versions in question.
REDUNDANT_IF_DOUBLE_ENV (string, see above)
Applies if /etc/portage/package.env matches twice for the versions in question.
REDUNDANT_IF_DOUBLE_CFLAGS (string, see above)
Applies if /etc/portage/package.cflags matches twice for the versions in question. Note that this file is not supported by portage, but you might e.g. have built some support for it in your personal /etc/portage/bashrc file. Of course, this means that also no format for /etc/portage/package.cflags is defined. eix assumes that the format is analogous to /etc/portage/package.{keywords,use} (i.e. an entry is at most one line, with the matching version(s) at the beginning). As the other /etc/portage/package.* files, /etc/portage/package.cflags may also be a directory tree; in this case, all non-hidden files/subdirectories in this tree are read recursively, resolving all symbolic links.
REDUNDANT_IF_IN_KEYWORDS (string, see above)
Applies if /etc/portage/package.keywords contains a nonempty entry matching the versions in question (to find empty entries use -t). Of course, one will certainly not consider all matches as a redundancy (although one might misuse this option to simply list all matches). However, one might consider matching but non-installed packages as redundant. Hence, typically one might want to set this variable to the value -some or the equivalent value -some-uninstalled (or to false if one thinks that entries for uninstalled packages are "normal" and not redundant).
REDUNDANT_IF_IN_MASK (string, see above)
This is analogous to REDUNDANT_IF_IN_KEYWORDS, but for /etc/portage/package.mask.
REDUNDANT_IF_IN_UNMASK (string, see above)
This is analogous to REDUNDANT_IF_IN_KEYWORDS, but for /etc/portage/package.unmask.
REDUNDANT_IF_IN_USE (string, see above)
This is analogous to REDUNDANT_IF_IN_KEYWORDS, but for /etc/portage/package.use.
REDUNDANT_IF_IN_ENV (string, see above)
This is analogous to REDUNDANT_IF_IN_KEYWORDS, but for /etc/portage/package.env.
REDUNDANT_IF_IN_CFLAGS (string, see above)
This is analogous to REDUNDANT_IF_IN_KEYWORDS, but for /etc/portage/package.cflags. See the above comments about this file.
SLOT_UPGRADE_FORBID (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.slot_upgrade_forbid
SLOT_UPGRADE_ALLOW (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.slot_upgrade_allow
KEYWORDS_NONEXISTENT (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.accept_keywords.nonexistent
MASK_NONEXISTENT (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.mask.nonexistent
UNMASK_NONEXISTENT (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.unmask.nonexistent
USE_NONEXISTENT (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.use.nonexistent
ENV_NONEXISTENT (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.env.nonexistent
CFLAGS_NONEXISTENT (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.cflags.nonexistent
INSTALLED_NONEXISTENT (string list)
This is a list of filenames/dirnames which serve as /etc/portage/package.installed.nonexistent
PACKAGE_NOWARN (string list)
This is a list of filenames/dirnames which serves as /etc/portage/package.nowarn
/etc/portage/sets.eix¶
This is a directory analogous to /etc/portage/sets (see the portage manpage). Since portage has some ways to define package sets which are not available for eix, you can use this directory to store (static) sets which you want that eix knows anyway (e.g. so that set entries in /etc/portage/package.keywords can be treated properly).
/etc/portage/package.slot_upgrade_forbid¶
/etc/portage/package.slot_upgrade_allow¶
Similarly as all other /etc/portage/package.*, this can be a file or directory. The entries of this file are of the form "category/name" (separated by newlines). The corresponding packages are treated as exceptions for UPGRADE_TO_HIGHEST_SLOT./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.cflags.nonexistent¶
Similarly as /etc/portage/package.*, this can be a file or a directory. If an entry (separated by space or newline) matches the first word of a line in the corresponding /etc/portage/package.{keywords,mask,unmask,use,cflags} file, this line is excluded from the -t tests (for names not in the database). You can use this to eliminate certain warning from -t./etc/portage/package.installed.nonexistent¶
This is similar to the other /etc/portage/package.*.nonexistent files/dirs with the difference that it eliminates messages from -t about installed packages which had been removed from the database. The entries of this file are of the form "category/name", but you can also omit the "category/" part (although this is not recommended)./etc/portage/package.nowarn¶
Similarly as /etc/portage/package.*, this can be a file or a directory. With this file/dir you can switch off test for -T for particular packages. The format of the file is similarly to /etc/portage/package.use with the difference that you can switch on/off tests. Exactly those lines apply for which at least one matching version is available. For example, the linessys-kernel/*-sources no_change weaker
>sys-kernel/hardened-sources-2.6.40 -weaker
in this file will cause that -T does not find the package sys-kernel/*-sources if the only cause for it would be that REDUNDANT_IF_NO_CHANGE or REDUNDANT_IF_WEAKER is set. An exception to this rule is only made for REDUNDANT_IF_WEAKER and for hardened-sources, if the latter is available at least in version 2.6.40. The order in the file plays no role: The "-" always takes precedence if it occurs somewhere.
You can list a package several times in this file; the listed tests are then cumulative for the corresponding package.
Available tests are in_keywords, no_change, double, mixed, weaker, minusasterisk, 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_cflags, double_cflags, the meaning corresponding to the according REDUNDNANT_IF_* variable.
In addition there are the tests nonexistent, masked, other_overlay which correspond to the respective variables TEST_FOR_NONEXISTENT, NONEXISTENT_IF_MASKED, NONEXISTENT_IF_OTHER_OVERLAY.
/var/cache/eix¶
This is the binary database for eix. The path can be changed with the EIX_CACHEFILE variable (which by default honours EPREFIX via delayed reference). But only when the unmodified path /var/cache/eix is used, eix-update will perform certain permission tests in advance.
versionsort¶
versionsort is a helper tool for scripts which serves two purposes. It cuts the version strings from its arguments or interprets the arguments themselves as version strings (depending on some heuristics). Then it outputs the version strings in a sorted order, according to the portage rules of version sorting. If there is more than one argument, each version (including the last one) is followed by a newline. For example,
versionsort gcc-4.4 4.4_alpha0 sys-devel/gcc-4.05 4.5
will output
4.05
4.4_alpha0
4.4
4.5
If you pass only one argument, eix is more sloppy about the version rules; even if the version part is not completely correct, it is guaranteed in this case that the output is string-equal to the version part. Thus, you can use versionsort with one argument to split the package name from the version part in a shell script by
split=1-font-adobe-75dpi-1.3-r1
version=`versionsort "X${split}"`; name=${split%"-${version}"}
Although currently it makes no difference, it is safer in such a case (concerning possible future extensions of the version format) to let the argument(s) start with a non-number (like X in the above example) to make sure that versionsort will really cut the version from the argument and cannot misinterpret the whole argument as a version.
BUGS (and sort of FAQ)¶
For bugreports use either or Gentoo's bugzilla
eix does not and probably never will support dependencies and/or useflags. In particular, this means that eix -u output will be in general different from the output of an emerge update command - rely only the latter for your system. This holds in particular also for the upgrades of packages with slots. The variable UPGRADE_TO_HIGHEST_SLOT and manual exceptions in /etc/portage/package.slot_upgrade_forbid or /etc/portage/package.slot_upgrade_allow, respectively, can be used to manually work around some of these shortcomings somewhat.
eix does not and never will fully support all sets which portage does support. Currently, it appears that even the proposed way of PROPERTIES=set to put packages in the tree will never be supported by eix (because eix would need full support for dependencies and useflags to handle these). As a workaround you can manually define such additional sets in /etc/portage/sets.eix. Moreover, eix does not and probably never will support reading of sets.conf files. If you specified additional sets/ directories e.g. in some overlay, you must add these additional directories manually to the EIX_LOCAL_SETS variable in /etc/eixrc. The easiest way to do the latter is to put an entry like
EIX_LOCAL_SETS_ADD="/path/to/overlay1/sets /path/to/overlay2/sets ..."into /etc/eixrc (see the description of EIX_LOCAL_SETS above).
eix-diff does never consider /etc/portage/profile. (Reason: The saved database contains only the masking state according to the original profile, but not the profile itself. On the other hand, /etc/portage/profile can only be interpreted when the profile is known.)
The output with the default OVERLAYS_LIST=all-used-renumbered is confusing when one wants to use the overlay number in some eix variable/command-argument.
There is no cache method setting which gets information from overlays (for which no portage cache metadata is available) fast and reliable - you must always choose between one of these two extremes. The default is the fast one, but it shows often false slots and has other problems.
All the EPREFIX/ROOT stuff is confusing. In particular, by the mere fact of allowing much of these variables, eix will always be vulnerable to local attacks if it is called with a possibly unsafe environment.
The previous default KEEP_VIRTUALS=true used to confuse people. However, with the new default, nobody will find out that this feature exists. :(
There is no default setting of OBSOLETE_MINUSASTERISK which satisfies both, people using old portage and people using new portage.
There are too many features: The documentation and configuration has become too complicated. On the other hand, there are still many things which cannot be configured...
HISTORY¶
eix was formerly known as portagedb. The name was changed because a part of portage is also called portagedb, which was a bit confusing for everyone.
The functionality of eix-update was once triggered by using the -u switch on eix. It was than separated to provide better maintainability. Thus update-eix came to life. Meanwhile, it is the same executable with functionality distinguished by its call name. and the original name update-eix was renamed into eix-update.
Also eix-diff was previously called diff-eix, eix-remote was previously called update-eix-remote, eix-layman was previously called update-eix-layman, and eix-functions.sh was previously called functions-eix.sh (and much earlier update-eix-functions.sh). The reason for all these renamings is to have a more consistent naming scheme: All programs belonging to eix now start with eix-* (with the exception of versionsort which is more or less just an independent tool). If you cannot get accustomed to this new naming scheme or have scripts depending on the old names, you can use symbolic links for the original names; this is explicitly supported and is not intended to be deprecated. Moreover, if you call eix' ./configure with --enable-obsolete-symlinks or --enable-obsolete-reminder then such symlinks (or wrappers which also print a reminder about the obsolete names, respectively) are installed automatically. However, such symlinks are not installed by default, because new users will not need them. So it is advisable to update your scripts to the new names if they should ever run on newer systems. Moreover, also in eix-functions.sh two functions have been renamed for consistency reasons (CallUpdateEix -> CallUpdate and ClearUpdateEixArgs -> ClearUpdateArgs), and also the internal variable they use has been renamed (but the latter was never intended to be used by scripts). If you use one of the above mentioned ./configure options, then also a wrapper for functions-eix.sh will be installed which supports the obsolete function names (and prints a warning when they are used in case of --enable-obsolete-reminder).
Since the introduction of the %{*VARIABLE} syntax in eix-0.8.0, it is not reasonable anymore to use different variable names for eix and eix-diff. Hence, all corresponding DIFF_* variables have vanished.The cache method metadata-flat was previously just called metadata. The cache method assign was previously called backport or portage-2.1. The cache method flat had previously the name portage-2.0 which was even preferred. Anyway, the obsolete names are still supported.
portage-2.1 and portage-2.1.1 doesn't remove the old dep-cache, thus eix might find packages that are not in portage anymore if the flat/assign cache method is used. To circumvent this, eix-sync used to delete the old cache (rm -rf /var/cache/edb/dep/*). Since most people have no need to use this cache method anymore and deleting the old cache slows down the next portage run, this is not the default anymore (but still available as an option which can be put into /etc/eix-sync.conf).
eix-sync used to default to gensync instead of layman. See the description of /etc/eix-sync.conf how you can still use the deprecated gensync if you want to.
eix-sync no longer supports logging; options -v and -V have been removed. This avoids problems like no visible output with EMERGE_DEFAULT_OPTS=--ask. You should now use redirection when you want to use eix-sync in a cronjob.
The mechanism described now by DEFAULT_MATCH_FIELD has changed. The previous (less powerful) MATCH_.*_IF and MATCH_ORDER variables are not supported anymore.
The ADD_CACHE_METHOD and ADD_OVERRIDE_CACHE_METHOD variables are no longer built-ins but only used implicitly in delayed substitution in the default of CACHE_METHOD and OVERRIDE_CACHE_METHOD. In particular, setting the latter variables in /etc/eixrc without adding the delayed substitution " %{ADD_CACHE_METHOD}" or " %{ADD_OVERRIDE_CACHE_METHOD}", respectively, will prevent the former variables to have any meaning.
Before eix-0.18.0, customizable version output properties like <installedversions:VAR> or <availableversions:VAR> did not exist. Instead there was a chaos of parameters for <installedversions:*> and a bulk of variants for printing available or installed versions for feeding the output to scripts like <fullvailableversions> etc. Now all this has vanished: The variables NAMEVERSIONS, EQNAMEVERSION, ANAMESLOT, ANAMEASLOT, NAMESLOT, NAMEASLOT, and DATESORT take the role of all the earlier variants (where DATESORT demonstrates a related example that was previously not available). See the description of these variables in eix --dump for details. To see the effect of such an example try e.g.
eix --format '<availableversions:ANAMESLOT:ANAMESLOT>' --pure-packages gcc
See also the comments for the -I option.
Since eix-0.20.0 the logical connectives for EXPRESSIONs have changed dramatically: Not only braces are now possible, also chains with -a and -o are now treated left-associative as most users would intuitively expect. The negation --not is now treated as a logical operation starting a new BRACE_OR_TEST and no longer considered as part of TEST_OPTIONS (which was a source of confusion for many users). Now --pipe is really handled as part of TEST_OPTIONS and does not implicitly introduce logical connectives.
With eix-0.20.1 all the previously used files /etc/portage/package.*.nowarn are no longer supported by default: They were replaced by the single file/dir /etc/portage/package.nowarn. If you still want to use the previous files, set OBSOLETE_NOWARN=true in the environment. See the description of the variable PACKAGE_NOWARN (in the output of eix --dump) to understand why this works.eix-installed was part of eix-test-obsolete before eix-0.22.4 which was rather confusing for users and for maintaining, since their task has nothing in common.
AUTHORS¶
Martin V\(:ath <vaeth at mathematik.uni-wuerzburg.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)
SEE ALSO¶
portage(5), fnmatch(3), regex(7), emerge(1), esearch(1), qsearch(1), layman(8)
The eix homepage provides further information and links.
23 Mar 2011