Section: Portage (1)
Updated: May 2013
egencache - generate metadata cache for ebuild repositories
[options] --update [ATOM]...
The egencache program generates metadata cache for ebuild repositories and
stores it in the metadata/md5-cache/ directory within the repository
itself, for distribution.
- --update [ATOM] ...
Update the metadata/md5-cache/ directory (generate metadata as necessary).
If no package atoms are specified then all will be updated. See ebuild(5)
for the details on package atom syntax.
Update the ChangeLog files from SCM logs (supported only in git repos).
Update the profiles/use.local.desc file from metadata.xml.
Update manifest files, and sign them if signing is enabled. This supports
parallelization if enabled via the --jobs option. The --thin-manifests
and --sign-manifests options may be used to manually override layout.conf
Location of the intermediate metadata cache which is stored in a different
format that includes eclass state. See the BUGS section for
information about why this is necessary.
Defaults to /var/cache/edb/dep.
Location of portage config files.
Defaults to /.
Override the PORTAGE_GPG_DIR variable.
Override the PORTAGE_GPG_KEY variable.
Causes EGENCACHE_DEFAULT_OPTS to be ignored.
Specifies the maximum number of ebuild processes to spawn simultaneously.
Also see the related --load-average option.
Specifies that maximum load allowed when spawning multiple jobs.
Override the portage tree location.
Override the PORTDIR_OVERLAY variable (requires that
--repo is also specified).
Preserve the comments found in the output use.local.desc file. This requires
the output file to exist before egencache is called.
Name of the repo to operate on (default repo is located at PORTDIR).
The name should correspond the value of a repo_name entry (see
portage(5)) from one of the repositories that is configured via the
PORTDIR or PORTDIR_OVERLAY variables (see make.conf(5)).
When used together with the --update action, this enables a workaround
for cases in which the content of a cache entry changes and neither the file
mtime nor size changes, preventing rsync from detecting changes. Such cases are
handled by bumping the mtime on the ebuild (and the corresponding cache entry).
This option should only be needed for distribution via something like
rsync(1), which relies on timestamps and file sizes to detect changes
(see bug 139134). It's not needed with git(1) since that uses a
more thorough mechanism which allows it to detect changed inode numbers
(described in racy-git.txt in the git technical docs).
- --sign-manifests< y | n >
Manually override layout.conf sign-manifests setting.
- --strict-manifests< y | n >
Manually override "strict" FEATURES setting.
- --thin-manifests< y | n >
Manually override layout.conf thin-manifests setting.
Exit successfully if only minor errors occurred, such as skipped cache
updates due to ebuilds that either fail to source or are not sourced
due to invalid Manifest entries.
output file for use.local.desc data (or '-' for stdout)
If this variable is set in make.conf(5) then any options that it
contains will be added to the beginning of the command line on every
invocation. These options will not be added if the
--ignore-default-opts option is specified.
Prior to portage-188.8.131.52, the 'pms' cache format was enabled by default.
This 'pms' format, which is distributed in the metadata/cache/
directory of the repository, has significant limitations related to the
cache validation mechanism which involves comparison of
a cache entry mtime to the mtime of the corresponding ebuild(5). This
mechanism is unreliable in cases when eclass changes result in metadata
changes, since no information about eclass state is available in the cache.
Also, since the mtime of the cache entry must correspond to that of the
ebuild, the cache format is only suitable for distribution via protocols
that preserve timestamps (such as rsync(1)). For cache that is
distributed via git(1) repositories, there is currently a workaround
implemented in emerge(1) --sync which updates ebuild mtimes
to match their corresponding cache entries (except for ebuilds that are
modified relative to HEAD).
In order to solve the above problems, the newer 'md5-dict' format has been
enabled by default since portage-184.108.40.206. This format is distributed in
the metadata/md5-cache/ directory of the repository, and includes
additional validation data in the form of digests for both the ebuild
and its inherited eclasses. WARNING: Portage versions prior to
portage-220.127.116.11 will NOT recognize the 'md5-dict' format unless it is
explicitly listed in metadata/layout.conf (refer to portage(5)
for example usage).
WARNING: For backward compatibility, the obsolete 'pms' cache format
will still be generated by default if the metadata/cache/ directory
exists in the repository. It can also be explicitly enabled via the
cache-formats setting in metadata/layout.conf (refer to portage(5)
for example usage). If the 'pms' cache format is enabled and the 'md5-dict'
format is not enabled, then it is necessary to enable
metadata-transfer in FEATURES (see make.conf(5)).
This causes intermediate cache (in a different format that includes
eclass state) to be generated inside the directory which is configurable
via the --cache-dir option.
Please report bugs via http://bugs.gentoo.org/
Zac Medico <email@example.com>
- ENVIRONMENT OPTIONS
- REPORTING BUGS
- SEE ALSO
This document was created by
using the manual pages.
Time: 00:30:41 GMT, May 19, 2013