Repository format/metadata/layout.conf

The metadata/layout.conf file is Article description::a file describing global properties of a repository.

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 #.

FILE metadata/layout.confAn example showing the format of the file

<syntaxhighlight lang="ini">key1 = value1
# comment
key2 = value2</syntaxhighlight>

Possible keys

This page contains only some of the possible keys and values in layout.conf. For a thorough listing, refer to the Portage manual:

user $man 5 portage

repo-name

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

FILE metadata/layout.confSpecifies repository name

<syntaxhighlight lang="ini">repo-name = foo-overlay</syntaxhighlight>

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 eclasses from one more more master repositories.

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

FILE metadata/layout.confAn example for repository relying on gentoo ebuild repository eclasses

<syntaxhighlight lang="ini">masters = gentoo</syntaxhighlight>

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

FILE metadata/layout.confAn example for repository relying on two other repositories

<syntaxhighlight lang="ini">masters = python gentoo</syntaxhighlight>

Finally, a stand-alone repository like gentoo should provide an empty masters list. This means that all eclasses used by packages in that repository must be found in that repository:

FILE metadata/layout.confAn example for a stand-alone repository

<syntaxhighlight lang="ini">masters =</syntaxhighlight>

eapis-banned

This setting bans EAPIs (repoman will fail):

FILE metadata/layout.confBans EAPI 0 and EAPI 1

<syntaxhighlight lang="ini">eapis-banned = 0 1</syntaxhighlight>

eapis-deprecated

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

FILE metadata/layout.confMarks EAPI 2 and EAPI 3 as deprecated

<syntaxhighlight lang="ini">eapis-deprecated = 2 3</syntaxhighlight>

sign-commits

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

FILE metadata/layout.confEnabling commit signing

<syntaxhighlight lang="ini">sign-commits = true</syntaxhighlight>

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

The key used to sign commits can be set through:

user $git config user.signingkey <keyid>

sign-manifests

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

FILE metadata/layout.confDisabling Manifest signing

<syntaxhighlight lang="ini">sign-manifests = false</syntaxhighlight>

In Portage, the manifest signing is enabled by adding sign to the FEATURES variable in /etc/portage/make.conf.

thin-manifests

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

FILE metadata/layout.confEnabling thin Manifests

<syntaxhighlight lang="ini">thin-manifests = true</syntaxhighlight>

use-manifests

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

FILE metadata/layout.confEnforce correct manifests

<syntaxhighlight lang="ini">use-manifests = strict</syntaxhighlight>

Possible values are strict to enforce manifest usage and false to disable manifest usage.

This article is issued from Gentoo. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.