Manual de Gentoo: PPC64/Trabajar/Portage
Bienvenido 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:
usuario $man emergeEl repositorio Gentoo
Ebuilds
Cuando hablamos sobre paquetes, nos referimos normalmente a programas software disponibles para los usuarios de Gentoo a través del repositorio Gentoo. Este repositorio es una colección de ebuilds, archivos que contienen toda la información que Portage necesita para mantener el software (instalar, buscar, etc.). Estos ebuilds residen por defecto en /var/db/repos/gentoo.
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.
Actualizar el repositorio Gentoo
El repositorio Gentoo se actualiza normalmente con rsync, una utilidad rápida de transferencia de archivos incremental. La actualización es muy sencilla, ya que la orden emerge proporciona una interfaz para rsync:
root #emerge --syncEn ocasiones, hay aplicadas restricciones de cortafuegos que impiden que rsync conecte con los servidores espejo. En estos casos, el repositorio Gentoo puede ser actualizado vía las instantáneas del mismo generadas diariamente. La herramienta emerge-webrsync recupera e instala en su sistema la instantánea mas reciente.
root #emerge-webrsyncMantenimiento del software
Buscar software
Para buscar software utilizando el repositorio Gentoo, puede emplear las funcionalidades de búsquedas propias de emerge. Por defecto, emerge --search 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:
user $emerge --search pdfSi quiere buscar también en las descripciones puede utilizar la opción --searchdesc (o -S).
user $emerge --searchdesc pdfCuando 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.
* net-print/cups-pdf
Latest version available: 1.5.2
Latest version installed: [ Not Installed ]
Size of downloaded files: 15 kB
Homepage: http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
Description: Provides a virtual printer for CUPS to produce PDF files.
License: GPL-2
Instalar software
Una vez que haya encontrado el nombre del software que necesite, puede fácilmente instalarlo con emerge: simplemente añada el nombre del paquete. Por ejemplo, para instalar gnumeric:
root #emerge --ask app-office/gnumericMuchas 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 --pretend. Por ejemplo:
root #emerge --pretend gnumericPara hacer lo mismo, pero elegir de forma interactiva si desea continuar o no con la instalación, agregue el indicador --ask:
root #emerge --ask gnumericCuando le pida a Portage que instale un paquete, descargará las fuentes necesarias desde Internet (si fuera necesario) y las guardará por defecto en /var/cache/distfiles/. Después, el paquete será descomprimido, compilado e instalado. Si quiere que Portage solamente descargue las fuentes sin instalarlas, añada la opción --fetchonly a la orden emerge:
root #emerge --fetchonly gnumericEncontrar 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 emerge -vp categoría/paquete:
root #emerge -vp media-libs/alsa-libThese are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/alsa-lib-1.1.3::gentoo USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB
La mejor manera de activar el ajuste USE doc es por paquete, por medio de /etc/portage/package.use, 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 lea la sección acerca de ajustes USE.
Una vez que el paquete está instalado, su documentación se encuentra normalmente en un subdirectorio llamado igual que el paquete dentro del directorio /usr/share/doc.
user $ls -l /usr/share/doc/alsa-lib-1.1.3total 16 -rw-r--r-- 1 root root 3098 Mar 9 15:36 asoundrc.txt.bz2 -rw-r--r-- 1 root root 672 Mar 9 15:36 ChangeLog.bz2 -rw-r--r-- 1 root root 1083 Mar 9 15:36 NOTES.bz2 -rw-r--r-- 1 root root 220 Mar 9 15:36 TODO.bz2
Una forma más segura de listar los ficheros de documentación instalados es utilizar la opción --filter de equery. equery se utiliza para consultar la base de datos de portage y se incluye como parte del paquete app-portage/gentoolkit:
user $equery files --filter=doc alsa-lib* Searching for alsa-lib in media-libs ... * Contents of media-libs/alsa-lib-1.1.3: /usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2 /usr/share/doc/alsa-lib-1.1.3/NOTES.bz2 /usr/share/doc/alsa-lib-1.1.3/TODO.bz2 /usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2
La opción --filter se puede utilizar con otras reglas para ver las localizaciones de instalación para muchos otros tipos de ficheros. La funcionalidad añadida se puede revisar en la página del manual de equery: man 1 equery.
Desinstar software
Para eliminar software de un sistema de forma segura, utilizar emerge --deselect. Esto le indicará a Portage que un paquete ya no es necesario y que está disponible para su limpieza a través de --depclean.
root #emerge --deselect gnumericCuando un paquete ya no es seleccionado, el paquete y sus dependencias que se instalaron automáticamente cuando se instaló el software, permanecerán. Para hacer que Portage localice todas las dependencias que puede ser eliminadas actualmente, utilice la funcionalidad de emerge --depclean. Hablaremos de esto un poco más adelante.
Actualizar el sistema
Para mantener el sistema en perfecto estado (incluidas las últimas actualizaciones de seguridad) es necesario actualizar el sistema regularmente. Como Portage sólo comprueba los ebuilds en el repositorio Gentoo, lo primero que hay que hacer es actualizar este repositorio usando emerge --sync. Después se puede actualizar el sistema usando emerge --deep --update @world.
Con --deep, Portage buscará las versiones más nuevas de las aplicaciones que están instaladas (bien explicitamente, bien como dependencias). Sin --deep, solo verificará las versiones de las aplicaciones que están instaladas explícitamente (las aplicaciones enumeradas en /var/lib/portage/world); no verificará sus dependencias. Por lo tanto, esta opción casi siempre debería usarse:
root #emerge --update --deep @worldEl comando de actualización estándar debe incluir --changed-use o --newuse debido a posibles cambios dentro de los perfiles del repositorio, o si se han modificado las configuraciones USE del sistema. Portage verificará entonces si el cambio requiere la instalación de nuevos paquetes o la recompilación de los existentes:
root #emerge --update --deep --newuse @worldMeta-paquetes
Algunos paquetes del repositorio Gentoo no tienen contenido real pero son utilizados para instalar un conjunto de paquetes. Por ejemplo, el paquete kde-plasma/plasma-meta instalará el entorno de escritorio KDE Plasma en su sistema incluyendo varios paquetes relacionados con Plasma y también sus dependencias.
Para eliminar dicho paquete del sistema, ejecutar emerge --deselect en el paquete no tendrá mucho efecto ya que las dependencias del paquete permanecen en el 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 emerge --depclean para eliminar las dependencias huérfanas. Cuando haya terminado, podría ser necesario reconstruir las aplicaciones que estuvieran enlazadas dinámicamente a las que acaban de ser eliminadas, a pesar de que recientemente se ha añadido a Portage soporte para este asunto.
Todo esto se lleva a cabo a través de dos órdenes:
root #emerge --update --deep --newuse @world
root #emerge --ask --depclean
Licencias
A partir de la versión 2.1.7 de Portage, puede aceptar o rechazar la instalación de software basada en esta licencia. Todos los paquetes del árbol contienen una entrada LICENSE en sus ebuilds. Ejecutando emerge --search categoría/paquete le mostrará la licencia del paquete.
A modo de exención de responsabilidad y limitación de responsabilidad, la variable LICENSE en un ebuild es meramente una guía para los desarrolladores y usuarios de Gentoo. No es una declaración legal ni una garantía de que reflejará la licencia de cada archivo instalado por un ebuild. No se debe confiar en ella para obtener una representación legal completamente precisa de todos los archivos proporcionados por un paquete. Para obtener garantías, los administradores de sistemas deben realizar una comprobación exhaustiva de cada archivo instalado por un paquete para comprobar el alineamiento y/o el cumplimiento de la licencia. Si se encuentra una inconsistencia en el ebuild, informe del error para sugerir un cambio en los valores asignados a la variable LICENSE del ebuild.
Por defecto, Portage permite licencias que son aprobadas explícitamente por la Fundación del Software Libre, la Iniciativa para el Código Abierto, o que siguen la Definición de Software Libre.
La variable que controla las licencias permitidas es ACCEPT_LICENSE, la cual se puede ajustar en el archivo /etc/portage/make.conf. En el siguiente ejemplo, se muestra este valor por defecto:
/etc/portage/make.confEl ajuste ACCEPT_LICENSE por defectoACCEPT_LICENSE="-* @FREE"
Con esta configuración, los paquetes con una licencia de software libre o de documentación se podrán instalar. No se podrá instalar software que no sea libre.
Es posible ajustar ACCEPT_LICENSE globalmente en /etc/portage/make.conf, o puede especificarlo de forma que afecte a solo un paquete en el fichero /etc/portage/package.license.
Por ejemplo, si quiere permitir la licencia google-chrome para usar el paquete www-client/google-chrome, añada lo siguiente a /etc/portage/package.license:
/etc/portage/package.licenseAceptar la licencia google-chrome para el paquete google-chromewww-client/google-chrome google-chrome
Esto permite la instalación del paquete www-client/google-chrome pero impide la instalación del paquete www-plugins/chrome-binary-plugins aunque tengan la misma licencencia.
O para permitir el normalmente necesario sys-kernel/linux-firmware:
/etc/portage/package.licenseAceptar las licencias para el paquete linux-firmware# Aceptación de la licencia para linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable
# Aceptación de cualquier licencia que permita la redistribución
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
Las licencias se almacenan en el directorio /var/db/repos/gentoo/licenses/, y los grupos de licencias se guardan en el archivo /var/db/repos/gentoo/profiles/license_groups. La primera entrada de cada línea en letras MAYÚSCULAS, es el nombre del grupo de licencias, y cada entrada detrás de ésta es una licencia individual.
Los grupos de licencias definidos en la variable ACCEPT_LICENSE se prefijan con un símbolo @. Un ajuste posible (que era el anterior que usaba Portage por defecto) es permitir todas la licencias excepto End User License Agreements (EULAs) (Acuerdo de licencia de usuario final o CLUF) que requiere leer y firmar un acuerdo de aceptación. Para conseguir esto, se deben aceptar todas las licencias (usando *) y entonces eliminar las licencias en el grupo EULA tal y como se indica a continuación.
/etc/portage/make.confAceptar todas las licencias excepto EULAsACCEPT_LICENSE="* -@EULA"
Observe que este ajuste también acepta software y documentación no libres.
Cuando Portage se queja
Terminología
Como mencionamos anteriormente, Portage es muy potente y soporta muchas características de las que carecen otras herramientas de gestión de software. Para comprender esto, explicaremos unos cuantos aspectos de Portage sin profundizar demasiado en los detalles.
Con Portage, diferentes versiones de un mismo paquete pueden coexistir en un sistema. Mientras otras distribuciones tienden a renombrar el paquete con sus versiones (por ejemplo gtk+2 and gtk+3). Portage usa una tecnología llamada SLOTs (ranuras). Un ebuild declara un cierto SLOT para su versión. Ebuilds con diferentes SLOTs pueden coexistir en el mismo sistema. Por ejemplo, el paquete gtk+ tiene ebuilds con SLOT="2" y SLOT="3".
También existen paquetes que proporcionan la misma funcionalidad pero están implementados de maneras distintas. Por ejemplo, metalogd, sysklogd, y syslog-ng son todos paquetes de registro del sistema. Aplicaciones que necesitan la disponibilidad de un "registrador del sistema" no pueden depender, por ejemplo, de metalogd, ya que el resto de registradores del sistema son igualmente válidos. Portage permite virtuals: cada paquete de registro del sistema se lista como una dependencia "exclusiva" del servicio de registro en el paquete virtual/logger de la categoría virtual, de esta forma las aplicaciones pueden depender del paquete virtual/logger. Cuando se instala el paquete, se obtendrá el primer paquete de registro mencionado, a menos que ya se haya instalado previamente un paquete que ofrezca el servicio (en este caso, la dependencia virtual ya está satisfecha).
Los programas del repositorio Gentoo puede residir en diferentes ramas. Por defecto, su sistema solamente acepta paquetes que Gentoo considera estables. La mayoría de los paquetes nuevos, cuando son aceptados, ingresan en la rama inestable. Esto implica que necesitan hacerse más pruebas antes de marcarlo como estable. Aunque los ebuilds de estos programas está en el repositorio Gentoo, Portage no los actualizará hasta que sean marcados como estables.
Algunos programas solo están disponibles para unas pocas arquitecturas. O los programas no funcionan en otras arquitecturas, o necesitan más pruebas, o el desarrollador que añade el programa al repositorio Gentoo no es capaz de verificar si el paquete funciona en diferentes arquitecturas.
Cada instalación de Gentoo adhiere un cierto perfil el cual contiene, entre otra información, la lista de paquetes necesarios para que el sistema funcione normalmente.
Paquetes bloqueados
[ebuild N ] x11-wm/i3-4.20.1 USE="-doc -test"
[blocks B ] x11-wm/i3 ("x11-wm/i3" is soft blocking x11-wm/i3-gaps-4.20.1)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
x11-wm/i3
(x11-wm/i3-gaps-4.20.1-1:0/0::gentoo, installed) pulled in by
x11-wm/i3-gaps required by @selected
Los ebuilds contienen campos específicos que informan a Portage sobre sus dependencias. Hay dos posibles dependencias: dependencias de compilación, declaradas en la variable DEPEND y dependencias en tiempo de ejecución, declaradas en RDEPEND. Cuando una de estas dependencias marca explícitamente un paquete o paquete virtual como no compatible, se produce un bloqueo.
Aunque las versiones recientes de Portage son lo suficientemente inteligentes para resolver los bloqueos de menor importancia sin necesidad de la intervención del usuario, ocasionalmente necesitará resolverlo a mano como se explica abajo.
Para corregir un bloqueo, los usuarios pueden optar por no instalar el paquete o desinstalar el paquete conflictivo para empezar y poder seguir. En el ejemplo dado, se puede optar por no instalar x11-wm/i3 o eliminar primero x11-wm/i3-gaps. Normalmente es mejor simplemente indicarle a Portage que ya no se desea el paquete, con emerge --deselect x11-wm/i3-gaps, por ejemplo, para eliminarlo del archivo de world en lugar de eliminar el paquete en sí de manera forzada.
También puede ocurrir que vea los paquetes en conflicto con operadores lógicos concretos, como por ejemplo <media-video/mplayer-1.0_rc1-r2. En este caso, actualizar a la versión más reciente del paquete bloqueante debería eliminar el bloqueo.
También es posible que dos paquetes que aún no se han instalado se estén bloqueando mutuamente. En este caso (poco frecuente), se debería investigar por que necesitamos instalar ambos. En la mayoría de los casos se puede realizar con uno solo de los paquetes. Si no, por favor envíe un informe de error al sistema de seguimiento de errores de Gentoo.
Paquetes enmascarados (masked)
!!! all ebuilds that could satisfy "bootsplash" have been masked.
!!! possible candidates are:
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))
Cuando quiera instalar un paquete que no está disponible para su sistema, recibirá un error de enmascaramiento. Debería probar a instalar una aplicación distinta que este disponible para su sistema o esperar hasta que el paquete este disponible. Siempre hay una razón para que un paquete esté enmascarado:
| Causa del enmascaramiento | Descripción |
|---|---|
| ~arch keyword | La aplicación no está suficientemente probada para estar en la rama estable. Espere unos días o semanas y pruebe de nuevo. |
| -arch keyword or -* keyword | La aplicación no funciona en la arquitectura de destino. Si no es así, informe del error. |
| Sin keyword | La aplicación aún no se ha probado en la arquitectura de destino. Pida al equipo de adaptación de la arquitectura que pruebe el paquete o que pruebelo por ellos e informe de los resultados en el sitio web Bugzilla de Gentoo. Consulte /etc/portage/package.accept_keywords y Accepting a keyword for a single package. |
| package.mask | El paquete se ha mostrado corrupto, inestable o aún peor y ha sido expresamente marcado como "no-usar". |
| profile | El paquete no es adecuado para su perfil (profile) actual. La aplicación, si es instalada, puede romper el sistema o simplemente no es compatible con el perfil en uso. |
| license | La licencia del paquete no es compatible con los valores de ACCEPT_LICENSE. Permitir su licencia o el grupo de licencias adecuado indicándolo en /etc/portage/make.conf o en /etc/portage/package.license |
Cambios necesarios en los ajustes USE
The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test
También puede que se muestre el siguiente mensaje de error, si no se ha habilitado --autounmask:
emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])
Esta advertencia y error suceden cuando se quiere instalar un paquete que no solo depende de otro paquete, sino que requiere que ese paquete se haya construido con un ajuste USE en particular (o un conjunto de ajustes USE). En el ejemplo dado, el paquete app-text/feelings necesita construirse con USE="test", sin embargo, este ajuste USE no está habilitado en el sistema.
Para resolver esta situación, puede añadir el ajuste USE requerido a sus ajustes globales en /etc/portage/make.conf, o definirlo específicamente para el paquete en /etc/portage/package.use.
Dependencias perdidas
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.
La aplicación que está tratando instalar depende de otro paquete que no esta disponible para su sistema. Por favor, compruebe Bugzilla para ver si el problema se conoce o no, en este caso informe de ello. A menos que este mezclando ramas esto no debería ocurrir y lo consideraremos un error.
Nombre ambiguo del ebuild
[ Results for search key : listen ]
[ Applications found : 2 ]
* dev-tinyos/listen [ Masked ]
Latest version available: 1.1.15
Latest version installed: [ Not Installed ]
Size of files: 10,032 kB
Homepage: http://www.tinyos.net/
Description: Raw listen for TinyOS
License: BSD
* media-sound/listen [ Masked ]
Latest version available: 0.6.3
Latest version installed: [ Not Installed ]
Size of files: 859 kB
Homepage: http://www.listen-project.org
Description: A Music player and management for GNOME
License: GPL-2
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.
La aplicación que quiere instalar tiene un nombre que corresponde con más de un paquete. Necesita aportar también el nombre de la categoría. Portage le informará de los posibles casos entre los que puede elegir.
Dependencias circulares
!!! Error: circular dependencies:
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2
Dos (o más) paquetes que quiere instalar dependen uno de otro y, por tanto, no pueden instalarse. Esto casi siempre se considera un error en el repositorio Gentoo. Por favor, vuelva a sincronizar después de un tiempo e inténtelo de nuevo. También puede comprobar Bugzilla para saber si se tiene conocimiento sobre el tema o si no, en cuyo caso informe sobre ello.
Fallo en la descarga
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered. Please see above for details.
Portage no es capaz de descargar las fuentes para una aplicación específica y tratará de continuar instalando el resto de aplicaciones (si es posible). Este fallo puede deberse a que un servidor réplica no esta bien sincronizado o a que el ebuild apunta a una localización incorrecta. El servidor donde residen las fuentes podría estar caído por alguna razón.
Pruebe después de una hora y vea si el problema persiste.
Protección del perfil del sistema
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.
Está intentando eliminar un paquete que es parte fundamental de su sistema. Éste se haya en su perfil y es necesario, por tanto, no debería ser eliminado del sistema.
Errores en la verificación de la integridad (digest)
>>> checking ebuild checksums
!!! Digest verification failed:
Esto es un síntoma de que algo no ha ido bien en el repositorio de Gentoo, a menudo causado por un error cometido cuando es envía un ebuild al repositorio de Gentoo.
Cuando falla la verificación de la integridad (digest), no intente recalcularla. El ejecutar ebuild algo manifest no va a resolver el problema, posiblemente lo podría empeorar.
En lugar de esto, espere una o dos hora que el repositorio se estabilice. Es probable que el error haya sido detectado enseguida, pero podrá tomar algún tiempo para que propague la corrección a los servidores rsync réplica. Mientras espera, revise Bugzilla a ver si alguien ya ha reportado el problema o pregunte en #gentoo (webchat) (IRC). Si no, siga adelante y cree una incidencia para el ebuild roto.
Una vez que compruebe que se ha reparado el error, tal vez quiera volver a sincronizar el repositorio de ebuilds de Gentoo para obtener la suma de control reparada.
Procure no sincronizar el repositorio de ebuilds de Gentoo más de una vez al día. Tal y como se indica en las directrices de netiqueta de Gentoo (también se muestra cuando se lanza emerge --sync), los usuarios que sincronicen sus repositorios muy a menudo serán bloqueados temporalmente para evitar que los sincronicen durante un tiempo. Los usuarios que abusen continuamente ignorando esta directriz podrían ser bloqueados indefinidamente. A menos que sea absolutamente necesario, en la mayoría de los casos es mejorar esperar 24 horas para sincronizar de nuevo de modo que las resincronizaciones no carguen los servidores réplica de Gentoo.