Repository format/metadata/layout.conf

The file is Article description::a file describing global properties of a repository.

Its behaviour is defined by GLEP 82. Implelementations may implement extensions but these cannot be relied upon by ebuilds or repositories wishing to be portable.

File format

 * The file consists of a number of key-value pairs, one pair per line, with the two separated by  (equal sign).
 * Comment lines start with.

Possible keys
This page contains only some of the possible keys and values in.

For a thorough listing, refer to:
 * GLEP 82 (authoritative)
 * the Portage manual:

repo-name
This setting specifies the name of the repository. It takes precedence over an existing value in profiles/repo_name:

aliases
Allows multiple names (separate from the primary name, see repo-name ) to be used to reference the repository. Unset by default. Space-separated.

masters
The masters key specifies a list of master repositories for this particular repository. Whenever installing an ebuild from the particular repository, the package manager can use ebuilds, eclasses, and (depending on the repository format used) profiles from one or more master repositories.

The most common example is a repository (overlay) which provides additional packages for Gentoo. Such a package uses resources from the gentoo ebuild repository:

A particular repository may have more than a single masters entry. These are not inherited over repositories. In the following example, everything from gentoo take precedence over everything in python that shares the same name:

Finally, a stand-alone repository like gentoo should provide an empty masters list. This means that all ebuilds (dependencies), eclasses, and so on in that repository must be found in that repository:

eapis-banned
This setting bans EAPIs (repoman will fail):

profile-eapis-banned
Similar to eapis-banned but for the EAPI used in profiles.

eapis-deprecated
This setting marks EAPIs as deprecated (repoman will prompt a warning):

profile-eapis-deprecated
Similar to eapis-deprecated but for the EAPI used in profiles.

sign-commits
If enabled, the commits made in this repository will be signed:

This applies only to git repositories. It requires git 1.7.9 or newer.

The key used to sign commits can be set through:

manifest-hashes
See Repository format/package/Manifest too.

Tools will support these hash algorithms when reading and creating Manifests for ebuilds. They may use a subset if some are unrecognized or not supported. Space-separated.

The default is implementation-defined.

manifest-required-hashes
This defines the list of hashes which must be present in a Manifest. Tools must regenerate (and refetch if required) Manifests if these hashes are not present.

sign-manifests
Enabled by default. If enabled, the manifest files will be signed whenever committing to this repository from a GPG-enabled client:

In Portage, the manifest signing is enabled by adding  to the FEATURES variable in.

thin-manifests
Disabled by default. If enabled, thin manifests will be used inside the repository instead of the regular manifests:

Repositories using thin-manifests will have only DIST entries in their Manifests.

use-manifests
Strict by default. Enforces a correct manifest for each package:

Possible values are:
 * to enforce manifest usage;
 * to allow and create Manifests, but mismatches are ignored;
 * to disable manifest usage.

update-changelog
Controls whether tools should write a ChangeLog. false by default.

cache-formats
Controls cache formats used by the repository. Default is implementation-defined.

profile-formats
Control functionality available to profiles in this repo such as which files may be dirs, or the syntax available in parent files. Use  if unsure. Default is  even though it is invalid to set this manually.

Possible values are            , and. Multiple options can be set.


 * is the format specified in PMS which has no extensions: the Portage extensions below exist to supplement functionality in this base specification
 * indicates that this repo contains profiles that may use directories for USE and mask configuration instead of just files
 * indicate that paths such as or  in profile parent files can be used to express paths relative to the root  directory of a repository
 * enables the per-profile bashrc mechanism
 * enables support for using the profile file to add atoms to the @profile package set
 * enables support for the profile_eapi_when_unspecified attribute of
 * allows dependency atoms in the profile to refer to specific builds (see the binpkg-multi-instance FEATURES setting in make.conf(5)). A build-id atom is identical to a version-specific atom, except that the version is followed by a hyphen and an integer build-id
 * allows dependency atoms in the profile to refer to specific repositories

properties-allowed
Controls the list of PROPERTIES tokens/values which are permitted for ebuilds within the repository. If set, development tools will warn on tokens in ebuilds which are not listed. If unset, all tokens are permitted.

restrict-allowed
Controls the list of RESTRICT tokens/values which are permitted for ebuilds within the repository. If set, development tools will warn on tokens in ebuilds which are not listed. If unset, all tokens are permitted.

External resources

 * https://www.gentoo.org/glep/glep-0082.html#configuration-keys - GLEP 82: Repository configuration file (layout.conf)