ebuild repository/es

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

Other languages:

Warning: Display title "ebuild repository/es" overrides earlier display title "Repositorio de ebuilds".

Resources

Un repositorio de ebuilds coloquialmente un recubrimiento (Overlay), es una estructura de directorios y ficheros utilizados para añadir y extender paquetes de software en un sistema basado en Gentoo. Los repositorios de ebuilds pueden contener ebuilds que se ajusten a una o más APIs de ebuild. Los respositorios de ebuild contienen ebuilds, eclasses y otros tipos de ficheros descriptivos de metadatos. Estos ficheros informan al gestor de paquete del software que está disponible para su instalación. Un repositorio de ebuilds debe respetar uno o más de las APIs Ebuild tal y como se describe en la Especificación del Gestor de Paquetes de Gentoo.

El repositorio inicial de un sistema Gentoo se llama el repositorio de ebuilds de Gentoo. Este término a veces se abrevia como Gentoo repo, ::gentoo, gentoo.git, o también simplemente "repo". Históricamente se conocía entre la comunidad de Gento como el árbol de Portage, el árbol rsync, o también simplemente "el árbol". El repositorio de ebuilds de Gentoo cotiene ebuilds que son mantenidas por los desarrolladores oficiales de Gentoo y también por miembros de la comunidad (a través del proyecto Proxy Maintainers).

Los administradores de los sistemas Gentoo pueden añadir repositorios de ebuilds adicionales utilizando diferentes herramientas y métodos que se describen más abajo.

Repositorios

Los repositorios de ebuilds no son más (o menos) que un conjunto de ficheros (ebuilds, ficheros de metadatos, ...). Éstos se pueden obtener de repositorios públicos (git, CVS, SVN, ...) o descargarse como ficheros empaquetados (tarballs) y desempaquetarse manualmente en el sistema.

Importante
Se recomienda utilizar repositorios gestionados por terceros de confianza. Cualquier repositorio de ebuilds instalado puede causar que Portage busque a través de los ficheros que han solapado a los del repositorio de Gentoo a la hora de decidir que software instalar. Si existe código comprometido en el repositorio de ebuilds, entonces se podrían instalar paquetes comprometidos en el sistema.

La forma actual por defecto para gestionar repositorios es a través de /etc/portage/repos.conf que, como muchas otras localizaciones de configuración de Portage, pueden ser un fichero o un directorio de ficheros.

Las definiciones de repositorio dentro de /etc/portage/repos.conf también informan a Portage si el repositorio se puede actualizar y cómo puede hacerse esta actualización. Con todo esto, al lanzar emaint sync --auto se actualizarán también los repositorios habilitados.

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

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

Prioridades

Cada repositorio de ebuilds tiene una prioridad única para el gestor de paquetes. 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) tendrán 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"):

user $emerge --info --verbose

user $portageq repos_config /

El repositorio de ebuilds de Gentoo tendrá una prioridad de -1000 lo que significa que el resto de repositorios de ebuilds tienen mayor precedencia si se les asigna un prioridad mayor. Este es el comportamiento por defecto ya que los repositorios de ebuilds se han diseñado para "solapar" o "colocarse encima" del repositorio de Gentoo. Para definir la prioridad de otros repositorios, se debe editar manualmente la sección relevante de repos.conf y definir priority = al valor deseado. Por ejemplo:

ARCHIVO /etc/portage/repos.conf/eselect-repo.confDefinir la prioridad de un repositorio

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

Los repositorios que no tienen una prioridad definida por defecto a 0.

Herramientas disponibles

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

Layman

La aplicación layman 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 make.conf como para el método repos.conf.

Cuando se utiliza el método make.conf, layman gestiona un archivo dedicado de configuración que debe ser cargado por make.conf
Cuando se utiliza repos.conf, layman gestiona el fichero /etc/portage/repos.conf/layman.conf directamente.

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

emaint

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

eix

eix-sync es un envoltorio para emerge --sync (que de hecho lanza emaint sync --auto) seguido de eix-update. Para más detalles, leer el artículo sobre Eix y man 1 eix.

eselect-repository

eselect repository mantiene las entradas /etc/portage/repos.conf para que Portage pueda acceder y sincronizar. Lea el artículo Eselect/Repository para más detalles.

Utilización

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 el especificador de versión::::

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

Se puede utilizar la misma notación para diferentes instrucciones de emerge, incluyendo la desinstalación de un paquete mediante --depclean.

Buenas prácticas

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 emerge --regen después de sincronizar los repositorios de ebuilds:

root #

emaint sync --allrepos

root #( ulimit -n 4096 && emerge --regen )

Hay que ser cuidadoso ya que emerge --regen 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 emerge --sync (o eix-sync) para regenerar la caché. Probablemente solo los usuarios de repositorios de ebuilds muy voluminosos deberían correr emerge --regen.

Enmascaramiento de repositorios de ebuild instalados pero inseguros

Cuando se utilizan repositorios de ebuilds con muchos paquetes o se cree que contienen código de baja o desconocida calidad, es una buena práctica enmascarar de forma dura (hard mask) todo el repositorio de ebuilds y únicamente aceptar determinados ebuilds basándose en una estrategia caso por caso. Por ejemplo, para un recubrimiento llamado "repository-foobar":

ARCHIVO /etc/portage/package.maskEnmascarar todos los paquetes de un repositorio de ebuilds

*/*::repository-foobar

A continuación añadir el paquete o paquetes específicos desde el recubrimiento repository-foobar de modo que estén disponibles y visibles para la instalación de Portage:

ARCHIVO /etc/portage/package.unmaskDesenmascarar un paquete específico en un repositorio de ebuilds

foo-category/bar::nombre-del-repositorio

Después del desenmascaramiento de arriba, el paquete llamado "foo-category/bar" debería estar disponible y ningún otro paquete del recubrimiento repository-foobar estaría disponible, lo que es así por diseño.

Véase también

Proyecto de Overlays. El proyecto oficial de Gentoo de soporte de repositorios de ebuilds.
Guía de Overlays (Proyecto Overlays). Una guía de usuario escrita por el proyecto Overlay.
Guía del desarrollador de Overlays en Gentoo. Este documento se conserva únicamente por razones históricas. La guía actual se mantiene en Project:Overlays/Overlays guide.
Definiendo un repositorio personalizado. La sección del manual de Gentoo

Recursos externos