Handbook:AMD64/Portage/Advanced

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Handbook:AMD64/Portage/Advanced and the translation is 100% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎italiano • ‎日本語 • ‎한국어 • ‎polski • ‎русский • ‎українська • ‎中文(中国大陆)‎
AMD64 Manual
Instalación
Acerca de la instalación
Elegir los medios
Configurar la red
Preparar los discos
Instalar el stage3
Instalar el sistema base
Configurar el núcleo
Configurar el sistema
Instalar las herramientas
Configurar el cargador de arranque
Terminar
Trabajar con Gentoo
Introducción a Portage
Ajustes USE
Características de Portage
Sistema de guiones de inicio
Variables de entorno
Trabajar con Portage
Ficheros y directorios
Variables
Mezclar ramas de software
Herramientas adicionales
Repositorios personalizados de paquetes
Características avanzadas
Configuración de la red
Comenzar
Configuración avanzada
Configuración de red modular
Conexión inalámbrica
Añadir funcionalidad
Gestión dinámica


Introducción

Para la mayoría de los usuarios, la información recibida hasta ahora es suficiente para todas sus operaciones en Linux. Sin embargo, Portage es capaz de mucho más; gran parte de sus características están dirigidas a usuarios avanzados o aplicable solo en casos muy particulares. En todo caso, esto es excusa para no documentarlas.

Por supuesto que con gran flexibilidad viene una gran lista de casos potenciales. No será posible documentarlos todos aquí. En cambio, esperamos poder enfocarnos en algunas situaciones genéricas que pueden ser modificadas para cumplir las necesidades de cada quien. Si requiere afinamientos o datos más específicos, intente encontrarlos más bien en el Wiki Gentoo.

La mayoría, si no todas estas características adicionales, se pueden encontrar fácilmente leyendo las páginas del manual que proporciona Portage:

user $man portage
user $man make.conf

Finalmente, sabemos que, si estas características avanzadas no son usadas correctamente, pueden hacer que el solucionar fallos sea muy difícil. Asegúrese de mencionarlas en caso crea que ha tropezado con un fallo y desea abrir un informe de error.

Variables de entorno por paquete

Usando /etc/portage/env

De manera predeterminada, se usarán en la construcción de un paquete las variables de entorno definidas en /etc/portage/make.conf, tales como CFLAGS, MAKEOPTS etc. Sin embargo, en algunos casos, tal vez quisiéramos proporcionar diferentes variables para paquetes específicos. Para esto, Portage soporta el uso de /etc/portage/env y /etc/portage/package.env.

El archivo /etc/portage/package.env contiene una lista de paquetes que proporcionan variables con valores distintos y un identificador específico que indica a Portage los cambios deseados. Portage buscará este identificador, cuyo nombre puede escoger uno mismo, en el archivo /etc/portage/env/IDENTIFICADOR.

Ejemplo: Depurando fallos en paquetes específicos

Como ejemplo, activaremos la depuración para el paquete media-video/mplayer.

Primero registramos las variables para depuración en un archivo llamado /etc/portage/env/depurar-cflags. El nombre es escogido arbitrariamente, pero por supuesto refleja claramente su razón de ser para que sea obvia en el futuro.

ARCHIVO /etc/portage/env/depurar-cflagsVariables específicas para depuración
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

Luego agregamos el rótulo al paquete media-video/mplayer para usar su contenido:

ARCHIVO /etc/portage/package.envUsar depurar-cflags con el paquete mplayer
media-video/mplayer depurar-cflags

Enganchándose en el proceso del emerge

Usando /etc/portage/bashrc y archivos relacionados

Al trabajar Portage con los ebuilds, usa un entorno bash en el cual llama las distintas funciones de construcción (como src_prepare, src_configure, pkg_postinst, etc.). Portage también permite que uno mismo establezca el entorno bash.

La ventaja de usar un entorno bash propio es poder engancharse en el proceso de emerge en cada paso realizado. Esto puede hacerse para cada emerge (por medio de /etc/portage/bashrc) o con entornos individuales por paquete (con /etc/portage/env, como expusimos anteriormente).

Para engancharse al proceso emerge, el entorno bash puede inspeccionar las variables EBUILD_PHASE, CATEGORY y las variables que siempre están disponibles durante el desarrollo del ebuild (tales como P, PF, ...). En base a los valores de estas variables, podemos ejecutar pasos adicionales.

Ejemplo: Actualizando bases de datos de archivos

En este ejemplo usaremos /etc/portage/bashrc para llamar algunas aplicaciones de bases de datos para asegurar que sus bases de datos estén actualizadas con respecto al sistema. En el ejemplo usaremos aide (una herramienta para detectar intrusiones) y updatedb (usado por mlocate), pero solo como ejemplo. No considere que esto sea una guía para AIDE.

Para usar /etc/portage/bashrc en este caso, necesitaremos "enganchar" a las funciones postrm (después de borrar archivos) y postinst (después de instalar archivos) porque es cuando los archivos en el sistema de archivos han sido cambiados.

ARCHIVO /etc/portage/bashrcEnganchando las fases postinst y postrm
if [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ];
then
  echo ":: Llamada a aide --update para actualizar su base de datos";
  aide --update;
  echo ":: Llamada a updatedb para actualizar su base de datos";
  updatedb;
fi

Ejecutando tareas después de --sync

La ubicación de /etc/portage/postsync.d

Hasta ahora hemos conversado acerca de engancharnos a procesos del ebuild. Sin embargo, Portage también tiene otra función importante: actualizar el repositorio de Gentoo. Para ejecutar tareas después de actualizar el repositorio de Gentoo, coloque el guión dentro de /etc/portage/postsync.d y asegúrese que esté marcado ejecutable.

Ejemplo: ejecutar eix-update

Aunque no haya usado eix-sync para actualizar el árbol, todavía puede actualizar su base de datos después de ejecutar la orden emerge --sync (o emerge-webrsync) colocando un enlace simbólico a /usr/bin/eix llamado eix-update en /etc/portage/postsync.d.

root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update
Nota
Si prefiere usar otro nombre, deberá escribir un guión que llame a /usr/bin/eix-update. El binario eix averigua cómo ha sido llamado y deduce qué función debe ejecutar. Si crea un enlace simbólico a eix que no sea eix-update, no se ejecutará correctamente.

Haciendo caso omiso a la configuración de perfil

La ubicación de /etc/portage/profile

De manera predeterminada, Gentoo usa la configuración del perfil apuntado por /etc/portage/make.profile (un enlace simbólico al directorio del perfil correcto). Estos perfiles definen configuraciones específicas al igual que hereda configuraciones de otros perfiles (por medio de su archivo parent).

Al usar /etc/portage/profile, podemos hacer caso omiso de las configuraciones de perfil, tales como packages (los paquetes considerados parte del conjunto system), ajustes use forzados y demás.

Ejemplo: Agregar nfs-utils al conjunto system

Si usa sistemas de archivo NFS en sistemas de archivos críticos, tal vez quiera "proteger" al paquete net-fs/nfs-utils para que forme parte de system, lo cual ocasionará fuertes advertencias por parte de Portage en caso que se tratara de borrar.

Para hacer esto, agregamos el paquete a /etc/portage/profile/packages, antecedido por un *:

ARCHIVO /etc/portage/profile/packagesMarcar nfs-utils como paquete del sistema (system)
*net-fs/nfs-utils

Aplicando parches no normados

Usando epatch_user

Nota
La función epatch_user se aplica en EAPIs menores o iguales que cinco, consultar la función eapply_user para EAPIs mayores o iguales que seis.

Para manejar varios ebuilds similarmente, los desarrolladores de ebuilds usan eclasses (que son librerías al nivel del intérprete de comandos) que definen funciones comunes. Una de estas eclasses es eutils.eclass que ofrece una función de gran ayuda llamda epatch_user.

La función epatch_user aplica parches encontrados en /etc/portage/patches/<categoria>/<paquete>[-<versión>[-<revisión>]] al código fuente, en el directorio que encuentre primero. Lamentablemente no todos los ebuilds llaman automáticamente a esta función, así que el solo hecho de colocar el parche en esta ubicación no implica que funcione siempre.

Con suerte, con la información proporcionada arriba, se puede llamar esta función para enganchar a, por ejemplo, la fase prepare. La función puede ser llamada cuantas veces lo desee, pero aplicará los parches una sola vez.

Ejemplo: Aplicando parches a Firefox

El paquete www-client/firefox es uno de los pocos que llaman a epatch_user desde el ebuild, de manera que no hace falta sustituir nada en particular.

Si necesita parchear Firefox (por ejemplo, en el caso en que un desarrollador le ofrezca un parche y le pidiera que compruebe si corrige una incidencia de la que ha informado), coloque el parche en /etc/portage/patches/www-client/firefox (probablemente sea mejor usar el nombre completo, incluyendo la versión para que el parche no interfiera con versiones posteriores) y vuelva a construir Firefox.