Ebuild repository

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Ebuild repository and the translation is 100% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎日本語 • ‎한국어 • ‎polski • ‎русский • ‎中文(中国大陆)‎

An ebuild repository, colloquially known as an overlay, is a structure of directories and files used to add and extend packages available to the system's package manager. Ebuild repositories are also used by Gentoo developers as training ground and staging area for new ebuilds. Ebuild repositories can contain ebuilds of one or more EAPIs.

Systems that have Gentoo installed typically have a single ebuild repository available on the system. This main repository, known as the Gentoo ebuild repository, contains ebuilds maintained by official Gentoo developers and members of the community (through the Proxy Maintainers project). System administrators can add additional ebuild repositories to the system using various utilities and methods described below.


Ebuild repositories are nothing more (or less) than a set of files (ebuilds, metadata files, ...). These can be pulled in from public repositories (git, CVS, SVN ...) or downloaded as tarballs and extracted manually onto the system. It is advised to use managed repositories by trusted third parties; any installed ebuild repository will cause Portage to look through the overlaid files when deciding which software to install. If compromised code is in the ebuild repository, then compromised packages could be installed on the system.

The now default approach for handling repositories is through /etc/portage/repos.conf which, like many other Portage related locations, can be a directory as well.

Repository definitions inside /etc/portage/repos.conf/ also inform Portage if and how the repository can be updated. With it, calling emerge --sync will automatically update the repositories as well.

A deprecated, yet still supported method is to use the PORTDIR_OVERLAY variable inside /etc/portage/make.conf. This variable can point to one or more additional locations on the file system where repositories are available. The use of the /etc/portage/repos.conf/ directory is highly preferred.

For more information, see /etc/portage/repos.conf and the Portage/Sync article.


Each ebuild repository has its unique priority. This makes sure that in the case of a specific version being found in several ebuild repositories, the resolution is unambiguous. Ebuilds from ebuild repositories with higher priority numbers (for example 60) take precedence over ebuilds from ebuild repositories with lower priorities (such as 50).

The list of ebuild repositories with their priorities can be obtained through the output of the following commands (look for the "Repositories" string):

user $emerge --info --verbose
user $portageq repos_config /

The Gentoo repository will have a priority of -1000. That means that all other ebuild repositories generally take precedence as they are assigned a higher priority. That is the default behavior, because ebuild repositories are designed to "lay over/on top" of the Gentoo repository.

Available software

A number of tools support or integrate with ebuild repositories.


The layman application makes it easier to manage and update multiple additional ebuild repositories. It is a command-line application through which publicly available ebuild repositories can be listed, subscribed to and unsubscribed from, as well as update those repositories.

It supports both the make.conf as well as repos.conf method.

For more information, see Layman and Project:Portage/Sync#Layman_configuration.


See the Sync (Portage project) article and man 1 emaint.


eix-sync is a wrapper starting emerge --sync (which in turn starts emaint sync --auto) followed by eix-update. For further details see the Eix article and man 1 eix.


Emerging a duplicate package

When working with ebuild repositories it is possible to encounter a situation where multiple versions of the same package are available from different ebuild repositories. Instruct Portage to install a specific package from a specific ebuild repository with the :: notation:

root #emerge --ask category/atom::repository-name

The same notation can be used for different emerge instructions, including uninstalling a package through --depclean.

Best practices

Cache generation

When large ebuild repositories are installed, Portage may take a long time to perform operations like dependency resolution. This is because ebuild repositories do not usually contain a metadata cache.

Generate a local metadata cache by running emerge --regen after syncing the ebuild repositories:

root #emaint sync --allrepos
root #( ulimit -n 4096 && emerge --regen )

Be careful, because emerge --regen takes a lot of time and it's not recommended for rsync users as rsync updates the cache using server-side caches (most of users of portage are rsync users). Rsync users should simply run emerge --sync (or eix-sync) to regenerate the cache. It's probably only users of very large ebuild repositories should try emerge --regen.

Masking installed but unsafe ebuild repositories

When using huge ebuild repositories or those with unknown/low quality it is best practice to hardmask the whole ebuild repository.

FILE /etc/portage/package.maskMask all packages in an ebuild repository

After that unmask the packages that will be installed.

FILE /etc/portage/package.unmaskUnmask a specific package in an ebuild repository

See also

External resources