Manual de Gentoo: MIPS/Portage/Avanzado
Introducción a las funciones avanzadas de Portage
Para la mayoría de los lectores, la información recibida hasta ahora es suficiente para todas sus operaciones con Linux. Pero Portage es capaz de mucho más; muchas de sus funciones están destinadas a fines de personalización avanzada o solo son aplicables en casos especiales.
Por supuesto, con tanta flexibilidad viene una lista enorme de casos potenciales. No será posible documentarlos todos aquí. En cambio, el objetivo es centrarse en algunos problemas genéricos que luego se puedan ampliar para que se adapten a un caso en particular. Se pueden encontrar más ajustes y consejos como estos en la wiki de Gentoo.
La mayoría, si no todas, estas características adicionales, se pueden encontrar fácilmente leyendo las páginas del manual que son proporcionadas por Portage:
user $man portage
user $man make.conf
Por último, tenga en cuenta que se trata de funciones avanzadas que, si no se configuran correctamente, pueden dificultar mucho la depuración y la resolución de problemas. Asegúrese de que cualquiera de estos tipos de personalización se mencione explícitamente al abrir un informe de errores.
Variables de entorno por paquete
Usar /etc/portage/env
De forma predeterminada, las compilaciones de paquetes utilizarán las variables de entorno definidas en /etc/portage/make.conf, como CFLAGS, MAKEOPTS y otras. En algunos casos, resulta beneficioso proporcionar variables diferentes para paquetes específicos. Para ello, Portage admite el uso del directorio /etc/portage/env y el archivo /etc/portage/package.env.
El archivo /etc/portage/package.env contiene una lista de paquetes para los que se necesitan variables de entorno diferentes, así como un identificador específico que indica a Portage qué archivo de identificación aplicar. El nombre del identificador tiene un formato libre. Portage buscará un archivo con exactamente el mismo nombre que el identificador, con distinción entre mayúsculas y minúsculas. Consulte el siguiente ejemplo para obtener más detalles.
Ejemplo: uso de la depuración para paquetes específicos
Como ejemplo, para activar la depuración para el paquete media-video/mplayer.
Establezca las variables de depuración en un archivo llamado /etc/portage/env/debug-cflags. El nombre del archivo se elige arbitrariamente, pero, por supuesto, el nombre refleja el propósito del archivo, lo que debería ser obvio, si se revisa más adelante, por qué existe el archivo. Será necesario crear el directorio /etc/portage/env si aún no existe:
root #mkdir /etc/portage/env/etc/portage/env/depurar-cflagsVariables específicas para depuración# Añadir -ggdb a CFLAGS para depuración
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"
A continuación, el paquete media-video/mplayer se 'etiqueta`" para utilizar el nuevo identificador de depuración en el archivo package.env:
/etc/portage/package.envUsar el identificador debug-cflags con el paquete mplayermedia-video/mplayer debug-cflags
Conectar con el proceso de emerge
Usar /etc/portage/bashrc y archivos relacionados
Cuando Portage trabaja con ebuilds, utiliza un entorno bash en el que llama a las distintas funciones de compilación (como src_prepare, src_configure, pkg_postinst, etc.). Portage permite a los administradores de sistemas configurar un entorno bash específico.
La ventaja de utilizar un entorno bash específico es que permite la conexión con el proceso emerge durante cada paso que realiza. Esto se puede hacer para cada emerge (a través de /etc/portage/bashrc) o mediante el uso de entornos por paquete (a través de /etc/portage/env como se explicó anteriormente).
Portage calls so-called phase hook functions if they are defined in /etc/portage/bashrc. These functions follow the naming convention pre_phase_name and post_phase_name. For example, Portage will call the post_pkg_postinst hook just after calling the pkg_postinst phase function.
Para conectar con el proceso, el entorno bash puede mirar las variables EBUILD_PHASE, CATEGORY, así como las variables que siempre están disponibles durante el desarrollo de ebuild (como P, PF, ...). En función de los valores de estas variables, se pueden ejecutar pasos y/o funciones adicionales.
Ejemplo: Actualizar la base de datos de archivos
En este ejemplo, se utilizará el archivo /etc/portage/bashrc para llamar a algunas aplicaciones de bases de datos de archivos a fin de garantizar que sus bases de datos estén actualizadas con el sistema. Las aplicaciones utilizadas en el ejemplo son aide (una herramienta de detección de intrusiones) y updatedb (para usar con mlocate), pero se consideran ejemplos. No considere esto como 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.
/etc/portage/bashrcEnganchando las fases postinst y postrmif [ "${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
post_pkg_postinst() { my_database_update; } post_pkg_postrm() { my_database_update; } }}
Ejecutar tareas después de sinconizar el repositorio de ebuilds
Usar la ubicación /etc/portage/postsync.d
Además de conectarse a las fases del ebuild, Portage ofrece otra opción para la funcionalidad de conexión: postsync.d. Este tipo de conexiones se ejecutan después de actualizar, también conocido como sincronización, el repositorio de ebuilds de Gentoo. Para ejecutar tareas después de actualizar el repositorio de Gentoo, coloque los scripts dentro del directorio /etc/portage/postsync.d. Asegúrese de que todos los archivos dentro del directorio hayan sido marcados como ejecutables o no se ejecutarán.
Ejemplo: ejecutar eix-update
Si no se utilizó eix-sync para actualizar la sincronización del repositorio, aún es posible actualizar la base de datos eix después de ejecutar emerge --sync (o emerge-webrsync) poniendo 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-updateSi se elige un nombre diferente, entonces debe ser un script que llame a /usr/bin/eix-update en su lugar. El binario eix analiza cómo se lo ha llamado para determinar qué función ejecutar. Si se creara un enlace simbólico que apuntara a eix pero no se llamara eix-update, no se ejecutaría correctamente.
Anulación de la configuración del perfil
Usar /etc/portage/profile
De forma predeterminada, Gentoo utiliza las configuraciones contenidas en el perfil al que apunta /etc/portage/make.profile, que es un enlace simbólico al directorio del perfil de destino. Estos perfiles definen tanto configuraciones específicas como configuraciones heredadas de otros perfiles (a través de sus archivos principales).
Al usar /etc/portage/profile, los administradores del sistema pueden anular configuraciones de perfil como paquetes (qué paquetes se consideran parte del conjunto del sistema), indicadores USE forzados y más.
Ejemplo: Agregar nfs-utils al conjunto system
Al utilizar sistemas de archivos basados en NFS para sistemas de archivos críticos, puede ser necesario marcar net-fs/nfs-utils como un paquete de sistema, lo que hará que Portage advierta notoriamente a los administradores en caso de que intenten desinstalarlo.
Para lograrlo, el paquete debe agregarse al archivo /etc/portage/profile/packages, antepuesto con un * (símbolo de asterisco):
/etc/portage/profile/packagesMarcar net-fs/nfs-utils como paquete del sistema (system)*net-fs/nfs-utils
Aplicación de parches no estándar
Aplicación de parches al código fuente mediante parches de usuario en /etc/portage/patches/
Los parches de usuario proporcionan una forma de aplicar parches al código fuente de un paquete cuando se extraen las fuentes antes de la instalación. Esto puede resultar útil para aplicar parches originales a errores no resueltos o simplemente para personalizaciones locales.
Los parches se deben colocar en /etc/portage/patches/. Se aplicarán automáticamente durante la instalación del paquete.
Los parches se pueden colocar en cualquiera de los siguientes directorios:
- /etc/portage/patches/${CATEGORY}/${P}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r1/
- /etc/portage/patches/${CATEGORY}/${PN}/ e.g. /etc/portage/patches/dev-lang/python-3.4.2/
- /etc/portage/patches/${CATEGORY}/${P}-${PR}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r0/
Ejemplo: Aplicar parches a Firefox
El paquete www-client/firefox es uno de los muchos que ya llaman a eapply_user (posiblemente de manera implícita) desde dentro del ebuild, por lo que no hay necesidad de anular nada específico.
Si por alguna razón (por ejemplo porque un desarrollador proporcionó un parche y pidió verificar si corrige el error informado) se desea parchar Firefox, todo lo que se necesita es poner el parche en /etc/portage/patches/www-client/firefox/ (puede que sea mejor usar el nombre completo y la versión para que el parche no interfiera con versiones posteriores) y reconstruir Firefox.