ebuild repository/de

This page is a translated version of the page Ebuild repository and the translation is 48% complete.

Other languages:

Warning: Display title "ebuild repository/de" overrides earlier display title "Ebuild-Repositorien".

Resources

An ebuild repository, colloquially known as an overlay, is a structure of directories and files used to add and extend software packages for a Gentoo-based system. Ebuild repositories contain ebuilds, eclasses, and other types of descriptive metadata files. These files inform the package manager of software available for installation. An ebuild repository should conform to one or more Ebuild APIs as detailed in Gentoo's Package Manager Specification.

The primary repository on a Gentoo system is called the Gentoo ebuild repository. This term is sometimes contextually abbreviated as Gentoo repo, ::gentoo, gentoo.git, or occasionally just "repo". It was historically known within the Gentoo community as the Portage tree, rsync tree, or sometimes just "the tree". The Gentoo ebuild repository contains ebuilds that are maintained by official Gentoo developers and members of the community (through the Proxy Maintainers project).

Administrator of Gentoo systems can add additional ebuild repositories by using various utilities and methods described below.

Repositorien

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.

Wichtig
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 configuration locations, can be a file or a directory of files.

Repository definitions inside /etc/portage/repos.conf also inform Portage if and how the repository can be updated. With it, calling emaint sync --auto will automatically update the enabled 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 additional 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.

Prioritäten

Each ebuild repository has a unique priority to the package manager. This ensures that in the case of a specific version being found in several ebuild repositories, the resolution is unambiguous. Ebuilds from repositories with higher priority numbers (for example 60) will take precedence over ebuilds from 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 ebuild repository will have a priority of -1000 which means that all other repositories generally take precedence if they are assigned a higher priority. This is the default behaviour, because ebuild repositories are designed to "lay over" or "on top" of the Gentoo repository. To set the priority of other repositories, manually edit the relevant repos.conf section and set priority = to the desired value. For example:

DATEI /etc/portage/repos.conf/eselect-repo.confSetzen der Priorität eines Repositoriums

# created by eselect-repo
  
[guru]
location = /var/db/repos/guru
sync-type = git
sync-uri = https://github.com/gentoo-mirror/guru.git
priority = 100

Repositories that do not have a priority set default to 0.

Verfügbare Software

A number of tools support or integrate with ebuild repositories.

Layman

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.

When using the make.conf method, layman manages a dedicated configuration file which should be sourced in by make.conf
When using repos.conf, layman manages the /etc/portage/repos.conf/layman.conf file directly

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

emaint

Siehe den Sync (Portage Projekt) Artikel und man 1 emaint.

eix

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.

Eselect-Repositorium

eselect repository maintains /etc/portage/repos.conf entries for Portage to access and synchronize. See Eselect/Repository article for details.

Bedienung

Ein dupliziertes Paket installieren

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 :: version specifier:

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

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

Bewährte Verfahren

Zwischenspeichererstellung

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.

Ein eingerichtetes aber unsicheres Repositorium maskieren

When using large ebuild repositories or those with unknown/low quality code, it is best practice to hard mask the whole ebuild repository and only accept specific ebuilds on a case-by-case basis. For example, for an overlay named "repository-foobar":

DATEI /etc/portage/package.maskMaske alle Pakete in einem Ebuild-Repositorium

*/*::repository-foobar

Then add the specific package(s) from the repository-foobar overlay so that they will be available visible to Portage for installation:

DATEI /etc/portage/package.unmaskUnmaske ein spezifisches Paket in einem Ebuild-Repositorium

foo-category/bar::repository-name

After the above unmask the package named "foo-category/bar" should be available and none of the other packages from the repository-foobar overlay will be available, which is by design.

Siehe auch

Overlays project - The official Gentoo project for ebuild repositories' support.
Overlays guide (Overlay project) - A user guide written by the Overlay project.
Developer's guide to Gentoo overlays - This document is kept only for historical purposes. The current guide is maintained as Project:Overlays/Overlays guide.
Defining a custom repository - Section in the Gentoo Handbook

Externe Ressourcen