Handbook:Parts/Working/Portage/es

Biemvenido a Portage
Portage es probablemente la más importante innovación de Gentoo en la gestión de software. Debido a su potente flexibilidad y una gran cantidad de funcionalidades, es frecuentemente apreciado como la mejor herramienta de gestión de software disponible para Linux.

Portage esta completamente escrito en Python y Bash y, por tanto, totalmente a la vista de los usuarios al ser ambos lenguajes interpretados.

La mayoría de usuarios trabajarán con Portage a través de la herramienta emerge. Este capítulo no pretende duplicar la información disponible en la página de man sobre emerge. Para una completa información sobre las opciones de emerge, por favor, consulte la página del manual:

Ebuilds
Cuando hablamos sobre paquetes, nos referimos normalmente a programas software disponibles para los usuarios de Gentoo a través del árbol Portage. El árbol Portage es una colección de ebuilds, archivos que contienen toda la información que Portage necesita para mantener el software (instalar, buscar, ...). Estos ebuilds residen por defecto en.

Cuando se pida a Portage que ejecute alguna acción relacionada con los programas, éste utilizará los ebuilds de su sistema como base. Por tanto, es importante que actualice los ebuilds de su sistema para que Portage conozca el nuevo software, actualizaciones de seguridad, etc.

Actualizando el árbol Portage
El árbol Portage se actualiza normalmente con, una utilidad rápida de transferencia de archivos incremental. La actualización es muy sencilla, ya que la orden  proporciona una interfaz para  :

Si no es capaz de realizar  debido a restricciones de cortafuegos puede actualizar su árbol Portage a través de nuestras tres imágenes de Portage generadas diariamente. La herramienta  automáticamente comprueba e instala la última en su sistema.

Una ventaja adicional de utilizar  es que permite al administrador descargar únicamente instantáneas del árbol portage que están firmadas con la clave GPG del equipo de ingeniería de versiones de Gentoo. Se puede encontrar más información sobre esto en la sección Características de Portage en Obteniendo instantáneas validadas del árbol Portage.

Buscar software
Para buscar software utilizando el árbol de Portage, puede emplear las funcionalidades de búsquedas propias de. Por defecto,  devuelve el nombre de los paquetes cuyo nombre coincide (tanto total como parcialmente) con el término de búsqueda introducido.

Por ejemplo, para buscar todos los paquetes que tengan "pdf" en su nombre:

Si quiere buscar también en las descripciones puede utilizar la opción  (o  ).

Cuando eche un vistazo al resultado, notará que le proporciona mucha información. Los campos son etiquetados claramente con lo cual no entraremos en explicar sus significados.

Ejemplo de salida de emerge --search

Instalar Software
Una vez que haya encontrado el nombre del software que necesite, puede fácilmente instalarlo con : simplemente añada el nombre del paquete. Por ejemplo, para instalar gnumeric:

Muchas aplicaciones dependen unas de otras, esto implica que cualquier intento de instalar un cierto paquete de software podría derivar en la instalación de varias dependencias. No se preocupe. Portage maneja también las dependencias. Si quiere conocer qué instalará Portage cuando le pida que instale un cierto paquete, añada la opción. Por ejemplo:

Cuando le pida a Portage que instale un paquete, descargará las fuentes necesarias desde Internet (si fuera necesario) y las guardará por defecto en. Después, el paquete será descomprimido, compilado e instalado. Si quiere que portage solamente descargue las fuentes sin instalarlas, añada la opción  a la orden emerge:

Encontrar la documentación de un paquete instalado
Muchos paquetes vienen con su propia documentación. Algunas veces, el ajuste USE "doc" determina si la documentación debe instalarse o no. Puede comprobar la existencia del ajuste USE "doc" con la orden.

La mejor manera de activar el ajuste USE doc es por paquete, por medio de, de manera que solo obtendrá la documentación para los paquetes que le interesan. Activando este ajuste de manera global puede causar problemas con dependencias circulares. Para más información, por favor lea el capítulo acerca de los Ajustes USE.

Una vez que el paquete está instalado, su documentación se encuentra normalmente en un subdirectorio llamado igual que el paquete, bajo el directorio /usr/share/doc. También puede obtener un listado de todos los archivos instalados con la herramienta  la cual es parte del paquete.

Desinstalando Software
Cuando quiera desinstalar un paquete software de su sistema, utilice. Esto le indicará a Portage que desinstale todos los archivos instalados por el paquete en su sistema excepto los archivos de configuración de esa aplicación si la había modificado después de la instalación. Esto le permite continuar trabajando con los mismos archivos de configuración si alguna vez decide volver a instalar la aplicación.

Cuando desinstala un paquete de su sistema, las dependencias de ese paquete que se instalaron automáticamente cuando instaló el software, permanecerán. Para hacer que Portage localice todas las dependencias que puede ser eliminadas actualmente, utilice la funcionalidad de emerge. Hablaremos de esto un poco más adelante.

Actualizando su Sistema
Para mantener su sistema en perfecto estado (sin mencionar la instalación de los últimas actualizaciones de seguridad) necesita actualizarlo frecuentemente. Partiendo de que Portage solamente comprueba los ebuilds en su árbol Portage, lo primero sería actualizar el propio árbol. Cuando tenga el árbol Portage actualizado, puede actualizar su sistema con. En el siguiente ejemplo, además hemos utilizado la opción  que le indica a Portage que muestre la lista de paquetes que quiere actualizar y pregunte si se quiere continuar:

Portage buscará entonces las nuevas versiones de las aplicaciones que explícitamente haya instalado (las listadas en ), sin embargo, no revisa minuciosamente sus dependencias. Si desea actualizar también esas dependencias, añada la opción :

Aunque esto no indica todos los paquetes: algunos paquetes de su sistema son necesarios durante los procesos de compilación y construcción de los paquetes, pero, una vez que los paquetes se han instalado, estas dependencias ya no se necesitan. Portage denomina a éstas dependencias de construcción (build dependencies). Para incluirlas en un ciclo de actualización, añada :

Ya que las actualizaciones de seguridad también afectan a paquetes que no han sido explícitamente instalados en el sistema (pero que son dependencias de otros programas), es recomendable ejecutar la orden de arriba de vez en cuando.

Si ha cambiado últimamente alguno de sus ajustes USE quizá quiera añadir también. Portage comprobará si los cambios requieren la instalación de nuevos paquetes o la recompilación de los existentes:

Meta-paquetes
Algunos paquetes del árbol Portage no tienen contenido real pero son utilizados para instalar un conjunto de paquetes. Por ejemplo, el paquete instalará un entorno KDE completo en su sistema incluyendo varios paquetes relacionados con KDE y también sus dependencias.

Si quiere desinstalar dicho paquete de su sistema, ejecutando  sobre el paquete no tendrá efecto total ya que las dependencias permanecerán en su sistema.

Portage tiene la funcionalidad de eliminar las dependencias huérfanas, pero la disponibilidad de software necesita que primero actualice completamente su sistema, incluyendo los nuevos cambios que ha aplicado si actualizó los ajustes USE. Después de esto, puede ejecutar  para eliminar las dependencias huérfanas. Cuando haya terminado, necesitará reconstruir las aplicaciones que estuvieran enlazadas dinámicamente a las que acaban de ser eliminadas pero no son necesarias.

Todo esto se lleva a cabo a través de tres órdenes:

es parte del paquete ; no olvide instalarlo primero:

Licenses
Beginning with Portage version 2.1.7, it is possible to accept or reject software installation based on its license. All packages in the tree contain a LICENSE entry in their ebuilds. Running  will show the package's license.

By default, Portage permits all licenses, except End User License Agreements (EULAs) that require reading and signing an acceptance agreement.

The variable that controls permitted licenses is called, which can be set in. In the next example, this default value is shown:

With this configuration, packages that require interaction during installation to approve their EULA will not be installable. Packages without an EULA will be installable.

It is possible to set  globally in, or to specify it on a per-package basis in.

For example, to allow the license for, add the following to :

This permits installation of truecrypt versions that have the license, but not versions with the  license.

License groups defined in  are prefixed with an  sign. A commonly requested setting is to only allow the installation of free software and documentation. To accomplish this, remove all currently accepted licenses (using ) and then only allow the licenses in the FREE group as follows:

In this case, "free" is mostly defined by the FSF and OSI. Any package whose license does not meet these requirements will not be installable on the system.

Terminology
As stated before, portage is extremely powerful and supports many features that other software management tools lack. To understand this, we explain a few aspects of portage without going into too much detail.

With portage different versions of a single package can coexist on a system. While other distributions tend to name their package to those versions (like freetype and freetype2) portage uses a technology called SLOTs. An ebuild declares a certain SLOT for its version. Ebuilds with different SLOTs can coexist on the same system. For instance, the freetype package has ebuilds with SLOT="1" and SLOT="2".

There are also packages that provide the same functionality but are implemented differently. For instance, metalogd, sysklogd and syslog-ng are all system loggers. Applications that rely on the availability of "a system logger" cannot depend on, for instance, metalogd, as the other system loggers are as good a choice as any. Portage allows for virtuals: each system logger is listed as an "exclusive" dependency of the logging service in the logger virtual package of the virtual category, so that applications can depend on the package. When installed, the package will pull in the first logging package mentioned in the package, unless a logging package was already installed (in which case the virtual is satisfied).

Software in the portage tree can reside in different branches. By default the system only accepts packages that Gentoo deems stable. Most new software titles, when committed, are added to the testing branch, meaning more testing needs to be done before it is marked as stable. Although the ebuilds for those software are in the portage tree, portage will not update them before they are placed in the stable branch.

Some softwares are only available for a few architectures. Or the software doesn't work on the other architectures, or it needs more testing, or the developer that committed the software to the portage tree is unable to verify if the package works on different architectures.

Each Gentoo installation also adheres to a certain profile which contains, amongst other information, the list of packages that are required for a system to function normally.

Blocked packages
Portage warning about blocked packages (with --pretend)

Portage warning about blocked packages (without --pretend)

Ebuilds contain specific fields that inform Portage about its dependencies. There are two possible dependencies: build dependencies, declared in DEPEND and run-time dependencies, declared in RDEPEND. When one of these dependencies explicitly marks a package or virtual as being not compatible, it triggers a blockage.

While recent versions of Portage are smart enough to work around minor blockages without user intervention, occasionally such blockages need to be resolved manually.

To fix a blockage, users can choose to not install the package or unmerge the conflicting package first. In the given example, one can opt not to install postfix or to remove ssmtp first.

Sometimes there are also blocking packages with specific atoms, such as. In this case, updating to a more recent version of the blocking package could remove the block.

It is also possible that two packages that are yet to be installed are blocking each other. In this rare case, try to find out why both would need to be installed. In most cases it is sufficient to do with one of the packages alone. If not, please file a bug on Gentoo's bugtracking system.

Masked packages
Portage warning about masked packages

Portage warning about masked packages - reason

When trying to install a package that isn't available for the system, this masking error occurs. Users should try installing a different application that is available for the system or wait until the package is marked as available. There is always a reason why a package is masked:


 * ~arch keyword
 * the application is not tested sufficiently to be put in the stable branch. Wait a few days or weeks and try again.


 * -arch keyword or -* keyword
 * the application does not work on your architecture. If you believe the package does work file a bug at our bugzilla website.


 * missing keyword
 * the application has not been tested on your architecture yet. Ask the architecture porting team to test the package or test it for them and report the findings on our bugzilla website.


 * package.mask
 * the package has been found corrupt, unstable or worse and has been deliberately marked as do-not-use.


 * profile
 * the package has been found not suitable for the current profile. The application might break the system if it is installed or is just not compatible with the profile currently in use.


 * license
 * the package's license is not compatible with the ACCEPT_LICENSE setting. Permit its license or the right license group by setting it in or in

Necessary USE flag changes
Portage warning about USE flag change requirement

The error message might also be displayed as follows, if  isn't set:

Portage error about USE flag change requirement

Such warning or error occurs when a package is requested for installation which not only depends on another package, but also requires that that package is built with a particular USE flag (or set of USE flags). In the given example, the package app-text/feelings needs to be built with USE="test", but this USE flag is not set on the system.

To resolve this, either add the requested USE flag to the global USE flags in, or set it for the specific package in.

Missing dependencies
Portage warning about missing dependency

The application to install depends on another package that is not available for the system. Please check bugzilla if the issue is known and if not, please report it. Unless the system is configured to mix branches, this should not occur and is therefore a bug.

Ambiguous ebuild name
Portage warning about ambiguous ebuild names

The application that is selected for installation has a name that corresponds with more than one package. Supply the category name as well to resolve this. Portage will inform the user about possible matches to choose from.

Circular dependencies
Portage warning about circular dependencies

Two (or more) packages to install depend on each other and can therefore not be installed. This is most likely a bug in one of the packages in the portage tree. Please resync after a while and try again. It might also be beneficial to check bugzilla to see if the issue is known and if not, report it.

Fetch failed
Portage warning about fetch failed

Portage was unable to download the sources for the given application and will try to continue installing the other applications (if applicable). This failure can be due to a mirror that has not synchronised correctly or because the ebuild points to an incorrect location. The server where the sources reside can also be down for some reason.

Retry after one hour to see if the issue still persists.

System profile protection
Portage warning about profile-protected package

The user has asked to remove a package that is part of the system's core packages. It is listed in the profile as required and should therefore not be removed from the system.

Digest verification failure
Digest verification failure

This is a sign that something is wrong with the portage tree -- often, it is because a developer may have made a mistake when committing a package to the tree.

When the digest verification fails, do not try to re-digest the package personally. Running  will not fix the problem; it will almost certainly make it worse!

Instead, wait an hour or two for the tree to settle down. It's likely that the error was noticed right away, but it can take a little time for the fix to trickle down the portage tree. Check Bugzilla and see if anyone has reported the problem yet or ask around on #gentoo (IRC). If not, go ahead and file a bug for the broken package.

Once the bug has been fixed, re-sync the portage tree to pick up the fixed digest.