Repositorio de ebuilds
emerge — configuration — ebuild repository — dispatch-conf
world file — USE flags — ebuilds — profiles
upgrades — using testing packages — binary packages
tools — gentoolkit — eselect
Portage FAQ — cheat sheet — FAQ
all articles
{{}}
Un repositorio de ebuilds es una estructura de sistema de archivos que puede proveer paquetes para su instalación en un sistema Gentoo. Los repositorios de ebuilds contienen ebuilds , eclasses y otros tipos de archivos de metadatos descriptivos que provee a Portage de paquetes, noticias , perfiles , etc.
El repositorio de ebuilds de Gentoo es el repositorio oficial y principal de Gentoo Linux . Contiene toda la inforamción necesaria para construir e instalar cada paquete que conforma Gentoo. Se pueden configurar repositorios de ebuilds adicionales (como GURU ) con Portage para dar una elección incluso mayor de paquetes.
Portage instalará la última versión disponible de un paquete de cualquier repositorio de ebuilds configurado, por defecto. Si la última versión disponible es provista por más de un repositorio, se elegirá según el orden de prioridad; de ahí viene el nombre coloquial de overlay o recubrimiento .
Los administradores de sistemas Gentoo pueden configurar repositorios ebuild adicionales a través de Portage gracias a las herramientas y métodos descritos a continuación.
El repositorio de ebuilds Gentoo
El repositorio de ebuilds Gentoo es el repositorio de ebuilds principal de un sistema Gentoo Linux, y es de donde vienen todos los paquetes por defecto. Es mantenido en el gitweb.gentoo.org servidor y se sincroniza en sistemas locales (en /var/db/repos/gentoo ) para estar disponibles para Portage .
El repositorio de ebuilds Gentoo contiene archivos ebuild que le dicen a Portage cómo construir e instalar cada paquete. Los ebuilds contienen metadatos, información de dependencias, y todas las cosas necesarias para conseguir que un paquete funcione.
Los metadatos dan el nombre del paquete, su versión, de dónde sacar las fuentes, sus ajustes USE disponibles, su licencia , página web, etc. La información de dependencias en los ebuilds permite a Portage solicitar cualquier otro paquete necesarior para construir y ejecutar un paquete que vaya a ser instalado. Nada más, ni nada menos. Las dependencias son muy granulares en Gentoo. Variarán incluso según los ajustes USE que se seleccionen. Quizá más importante es el hecho de que los ebuilds contengan la información requerida para configurar , construir (compilar), instalar , y probar cada paquete; por lo general, partiendo del código fuente del mismo proyecto.
Además de los ebuilds, el repositorio de ebuilds Gentoo contiene los perfiles oficiales, los cuales definen el estado predeterminado de los USE flags , los valores por defecto de la mayoría de variables que se encuentran en /etc/portage/make.conf , el conjunto de paquetes de sistema , etc.
El repositorio de ebuilds Gentoo también es el lugar donde se publican noticias , por lo que puede que surjan nuevas noticias tras sincronizar el repositorio de ebuilds Gentoo.
El repositorio de ebuilds Gentoo , y sus ebuilds, son mantenidos por los desarrolladores de Gentoo y otros miembros de la comunidad .
A veces nos referimos al repositorio de ebuilds Gentoo por nombres más cortos o incluso coloquiales, como el repositorio de Gentoo , el repo de Gentoo , ::gentoo , gentoo.git , o, ocasionalmente, simplemente " repo ". Históricamente, en la comunidad, también se le ha llamado el árbol Portage , árbol rsync , o a veces simplemente " el árbol ".
GURU es un repositorio de ebuilds oficial mantenido de manera colaborativa por usuarios de Gentoo, con una ligera ayuda de algunos desarrolladores de Gentoo. Es complementario al repositorio de ebuilds Gentoo , y los mantenedores buscan mantener un nivel de calidad de los paquetes provistos razonable. También hay una lista de repositorios de ebuilds públicos registrados en repos.gentoo.org .
¿De dónde vienen los repositorios de ebuilds?
Como un repositorio de ebuilds es, simplemente, una estructura de archivos y directorios, un repositorio de ebuilds nuevo puede estar disponible a Portage copiando estos archivos y directorios a un lugar que le sea conocido a Portage. Los repositorios ebuild y sus archivos están típicamente en /var/db/repos/ , pero el lugar de los repositorios configurados para Portage se especifica en /etc/portage/repos.conf . Los repositorios de ebuilds pueden ser configurados en cualquier sistema de archivos, incluso en un nfs o SSHFS , permitiendo el almacenamiento de estos en un servidor en red o de Internet.
Como se ha mencionado anteriormente, el repositorio de ebuilds Gentoo se alberga en gitweb.gentoo.org . Este servidor también contiene otros repositorios de ebuilds .
En la práctica, los repositorios de ebuilds adicionales no se suelen simplemente copiar a una carpeta y configurados para Portage a mano (o sea, añadiéndolos a /etc/portage/repos.conf ). Generalmente, los nuevos repositorios son ofrecidos por terceros, y una vez configurados para Portage, se sincronizan ' con el mismo. La sincronización copia todos los archivos de un lugar remoto a un sistema de archivos disponible localmente, según la configuración.
Dado que los repositorios de ebuilds son simples estructuras de archivos, existen muchos métodos para sincronizarlos, y Portage ofrece multitud de posibilidades. Rsync es el método de sincronización por defecto y git también es popular. El método de sincronización se especifica en /etc/portage/repos.conf a la hora de configurar un repositorio, junto a la información necesaria para solicitarlo.
Gestión de repositorios
Se puede usar la herramienta eselect repository para añadir, desactivar o eliminar repositorios de ebuilds configurados con Portage fácilmente. Esta herramienta también provee una manera útil de listar y añadir cualquier repositorio registrado en repos.gentoo.org .
Los repositorios de ebuilds siempre pueden ser configurados manualmente a través de la edición de /etc/portage/repos.conf .
While the Gentoo ebuild repository is either written or reviewed by Gentoo developers, and the GURU repository has some developer oversight, that is not always the case for other ebuild repositories. It is possible that some ebuild repositories might contain vulnerable, badly broken or, theoretically, even malicious software.
New ebuild repositories for use with Portage can also be created by the user .
Se puede obtener la lista de repositorios de ebuilds a través de uno de los siguentes comandos:
user
$
emerge --info
user
$
portageq repos_config /
Instalación de paquetes desde otros repositorios
Packages from repositories other than the Gentoo ebuild repository can be installed with the emerge command, just as usual.
For example, once the GURU repository is added, to install the x11-misc/xbanish package from that repository:
root
#
emerge --ask x11-misc/xbanish
These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 2.96 s. [ebuild R #] x11-misc/xbanish-1.7::guru 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Note that the repository is not specified in the command. The "::guru" appended to the package atom in the output shows what repository the package will be installed from. This works because the x11-misc/xbanish package is present in the GURU repository, but not in the Gentoo repository.
If multiple versions of the same package are available from two or more different ebuild repositories, Portage will install the most recent version.
{{{1}}}
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
).
It is possible to instruct
Portage
to install a package from a specific ebuild repository with the
::
version specifier
(can be used for different emerge instructions, e.g. uninstalling a package through
--depclean
):
root
#
emerge --ask category/atom::repository-name
See the repository management section to see how to list repositories configured for portage with their respective priorities.
Repository synchronization
Ebuild repositories should be synchronized , so that the local mirrors will reflect a recent state of the repositories. This is necessary to be able to keep the system up to date , and install current software.
Regularly synchronizing with the Gentoo repository and updating the system in this way is important, to ensure that all the latest security updates are installed, and that the local system does not get too out of sync with the Gentoo repository , as this can make upgrades complicated if things have moved too far on in the repository.
Synchronize and update between daily or weekly to keep a Gentoo Linux installation running smoothly with the latest security updates. Waiting more than a few weeks to update may make things a little more complicated when the update is attempted. Please don't synchronize more than once daily, to avoid strain on the servers.
If local repositories are not very up to date, synchronize the repositories and update the system, before installing packages .
Lea el artículo Sync (Portage project) y man 1 emaint .
user
$
emaint --help
usage: usage: emaint [options] COMMAND
The emaint program provides an interface to system health checks
and maintenance. See the emaint(1) man page for additional
information about the following commands:
Commands:
all Perform all supported commands
binhost Scan and generate metadata indexes for binary packages.
cleanconfmem Check and clean the config tracker list for uninstalled packages.
cleanresume Discard emerge --resume merge lists
logs Check and clean old logs in the PORTAGE_LOGDIR.
merges Scan for failed merges and fix them.
movebin Perform package move updates for binary packages
moveinst Perform package move updates for installed and binary packages.
sync Check repos.conf settings and sync repositories.
world Check and fix problems in the world file.
optional arguments:
-h, --help show this help message and exit
-c, --check Check for problems (a default option for most modules)
-f, --fix Attempt to fix problems (a default option for most modules)
--version show program's version number and exit
-C, --clean Cleans out logs more than 7 days old (cleanlogs only) module-options: -t, -p
-t NUM, --time NUM (cleanlogs only): -t, --time Delete logs older than NUM of days
-p, --pretend (cleanlogs only): -p, --pretend Output logs that would be deleted
-P, --purge Removes the list of previously failed merges. WARNING: Only use this option if you plan on manually fixing them or do not want them re-installed.
-y, --yes (merges submodule only): Do not prompt for emerge invocations
-r REPO, --repo REPO (sync module only): -r, --repo Sync the specified repo
-A, --allrepos (sync module only): -A, --allrepos Sync all repos that have a sync-url defined
-a, --auto (sync module only): -a, --auto Sync auto-sync enabled repos only
--sync-submodule {glsa,news,profiles}
(sync module only): Restrict sync to the specified submodule(s)
To sync all repositories for which
auto-sync=true
is set, run
emaint sync
with the
--auto
switch (
-a
for short). This is usually the
command that should be run regularly
, before system updates and package installation (and is equivalent to using the old
emerge --sync
command):
root
#
emaint sync --auto
To sync the foo repository (irrespective of the foo auto-sync setting):
root
#
emaint sync --repo foo
Para sincronizar todos los repositorios con un tipo de sincronización y una URL de sincronización válidos (ignorando los ajustes de sincronización automática):
root
#
emaint sync --allrepos
For any repositories that should not be synced when running emaint sync --auto ,
auto-sync = no
must
be set in the appropriate file in
/etc/portage/repos.conf
, due to the default being
auto-sync = true
.
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 .
The emerge-webrsync tool can be used to download and install the daily Gentoo Repository rsync snapshot, to help with firewall restrictions, or to speed up the first synchronization, for example.
See man emaint for information on how to use the portage synchronization commands. See the Portage project sync article about migrating to the new modular sync system from Portage version 2.2.16, it contains important information, notably for users of eix-sync , esync -l , and emerge --sync .
Buenas prácticas
Generación de caché
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":
/etc/portage/package.mask
Enmascarar 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:
/etc/portage/package.unmask
Desenmascarar un paquete específico en un repositorio de ebuilds
foo-categoría/bar::repositorio-foobar
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
- Creating an ebuild repository — basics of creating an ebuild repository and maintaining ebuilds in it.
- Creating a custom ebuild repository - Sección en el Manual Gentoo.
- Guía de recubrimientos (Proyecto overlay) - Una guía de usuario escrita por el proyecto overlay
- Proyecto de overlays - El proyecto oficial de Gentoo para soporte de repositorios de ebuilds de recubrimiento.
Recursos externos
- https://repos.gentoo.org - Servidor oficial del repositorio de ebuilds Gentoo.
- https://github.com/gentoo/ - Espejo en GitHub del repositorio de ebuilds Gentoo.
- https://gpo.zugaina.org/Overlays - Una página web muy útil para buscar recubrimientos (overlays) no oficiales.