Repositorio de ebuilds

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Ebuild repository and the translation is 46% complete.
Outdated translations are marked like this.
Other languages:
Portage - the heart of Gentoo
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

{{}}

Resources

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, sulicencia, 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.

Nota
The Gentoo ebuild repository will sometimes be called by shorter, or even colloquial, names, such as the Gentoo repository, the Gentoo repo, ::gentoo, gentoo.git, or occasionally just the "repo". It is also historically and commonly known within the Gentoo community as the Portage tree, rsync tree, or sometimes just "the tree".
Consejo
GURU is an official ebuild repository maintained collaboratively by Gentoo users, with a little help from a few Gentoo developers. It is complementary to the Gentoo ebuild repository, and the maintainers strive to keep up a reasonable level of quality for the packages provided. There is also a list of public ebuild repositories registered on repos.gentoo.org.

¿De dónde vienen los repositorios de ebuilds?

Because an ebuild repository is simply a structure of files and directories, a new ebuild repository can be made available to Portage simply by copying those files and directories to a location known to Portage. The ebuild repositories and their files are usually under /var/db/repos/, but the location of repositories configured for Portage is specified in /etc/portage/repos.conf. Ebuild repositories can be configured on any accessible filesystem however, even on an nfs or SSHFS filesystem - allowing them to be stored on a network or Internet server.

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.

In practice, any additional ebuild repositories usually aren't just copied to a directory by hand and configured for Portage (meaning added to /etc/portage/repos.conf). Generally, new repositories are made available by third parties, and once configured for Portage, are synchronized by Portage. Synchronization mirrors all the files from a remote location to a locally available filesystem, as configured.

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

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.

Los repositorios de ebuilds siempre pueden ser configurados manualmente a través de la edición de /etc/portage/repos.conf.

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

Consejo
{{{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.

Nota
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.
Consejo
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.
Importante
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

To sync all repositories with a valid sync-type and sync-url defined (ignoring auto-sync settings):

root #emaint sync --allrepos
Advertencia
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.

Consejo
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":

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

Recursos externos

Retrieved from "https://wiki.gentoo.org/index.php?title=Ebuild_repository/es&oldid=1381232"