Ebuild repository/es

An ebuild repository, historically known as overlay, is Article description::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.

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

La forma actual por defecto para gestionar repositorios es a través de que, como otras localizaciones de Portage, también puede ser un directorio.

Las definiciones de repositorio dentro de también informan a Portage si el repositorio se puede actualizar y cómo se puede realizar. Con todo esto, la lanzar se actualizarán todos los repositorios.

Un método ya obsoleto pero aún permitido es utilizar la variable PORTDIR_OVERLAY dentro de. Esta variable puede apuntar a más de una localización adicional en el sistema de ficheros donde se pueden localizar repositorios. Sin embargo es preferible utilizar el directorio.

Para más información leer sobre /etc/portage/repos.conf y el artículo de Portage/Sync.

Prioridades
Cada repositorio de ebuilds tiene su propia prioridad única. Esto asegura que en el caso de que una versión en particular se encuentre en varios repositorios de ebuilds, la resolución de la misma no es ambigua. Los ebuilds de los repositorios con números de prioridad más altos (por ejemplo 60) tienen preferencia sobre los ebuilds de repositorios con menores prioridades (por ejemplo 50).

Se puede obtener la lista de repositorio de ebuilds y sus prioridades consultando la salida de las siguientes ordenes (Buscar la palabra "Repositories"):

El repositorio de Gentoo tendrá una prioridad de -1000. Esto implica que, por lo general, el resto de repositorios de ebuilds tienen mayor precedencia ya que se les asigna un prioridad mayor. Este es el comportamiento por defecto ya que los repositorios de ebuilds se han diseñado para "colocarse encima" del repositorio de Gentoo.

Herramientas disponibles
Existen algunas herramientas de soporte para integrar los repositorios de ebuilds.

Layman
La aplicación facilita la gestión y actualización de múltiples repositorios de ebuilds adicionales. Se trata de una aplicación de la línea de órdenes a través de la cual se pueden listar los repositorios de ebuilds disponibles al público, suscritos o no suscritos así como la actualización de esos repositorios.

Se ofrece soporte tanto para el método como para el método.
 * Cuando se utiliza el método, gestiona un archivo dedicado de configuración que debe ser cargado por
 * Cuando se utiliza, gestiona el fichero  directamente.

Para más información, consultar Layman y Project:Portage/Sync.

emaint
Lea el artículo Sync (Portage project) y.

eix
es un envoltorio para (que de hecho arranca ) seguido de. Para más detalles, leer el artículo sobre Eix y su página del manual.

Hacer emerge de un paquete duplicado
Cuando se trabaja con repositorios de ebuilds es posible encontrarse en la situación en que existen varias versiones del mismo paquete en diferentes repositorios de ebuilds. Se puede indicar a Portage que instale paquetes específicos desde un repositorio de ebuilds específico usando la notación :

Generación de cache
Cuando se instalan repositorios de ebuilds muy voluminosos, a Portage le puede llevar mucho tiempo realizar operaciones como la resolución de dependencias. Esto es debido a que los repositorios de ebuilds no suelen contener una caché para los metadatos.

Generar una caché local para metadatos lanzando después de sincronizar los repositorios de ebuilds:

Hay que ser cuidadoso ya que lleva bastante tiempo y no se recomienda a los usuarios de rsync ya que rsync actualiza la caché usando caché del servidor (la mayoría de los usuarios de portage son usuarios rsync). Estos usuarios deberían simplemente lanzar (o ) para regenerar la caché. Probablemente solo los usuarios de repositorios de ebuilds muy voluminosos deberían correr.

Masking installed but unsafe ebuild repositories
Cuando se utilizan repositorios de ebuilds con muchos paquetes o se cree que son de baja o desconocida calidad, es una buena práctica enmascarar todo el repositorio de ebuilds.

Después de esto, desenmascarar los paquetes que se instalarán.

Véase también

 * 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

Recursos externos

 * https://overlays.gentoo.org
 * https://github.com/gentoo/
 * https://gpo.zugaina.org/Overlays