Handbook:Parts/Portage/Advanced/es

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:

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.

Usando /etc/portage/env
De manera predeterminada, se usarán en la construcción de un paquete las variables de entorno definidas en, 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 y.

El archivo 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.

Ejemplo: Depurando fallos en paquetes específicos
Como ejemplo, activaremos la depuración para el paquete.

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

Luego agregamos el rótulo al paquete para usar su contenido:

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,  ,  , 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 ) o con entornos individuales por paquete (con, 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 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 (una herramienta para detectar intrusiones) y  (usado por ), pero solo como ejemplo. No considere que esto sea una guía para AIDE.

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

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  y asegúrese que esté marcado ejecutable.

Ejemplo: ejecutar eix-update
Aunque no haya usado para actualizar el árbol, todavía puede actualizar su base de datos después de ejecutar la orden  (o ) colocando un enlace simbólico a  llamado  en.

La ubicación de /etc/portage/profile
De manera predeterminada, Gentoo usa la configuración del perfil apuntado por (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, 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 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, antecedido por un :

Usando epatch_user
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 que ofrece una función de gran ayuda llamda.

La función  aplica parches encontrados en  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 es uno de los pocos que llaman a   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 (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.