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
In this example, we'll use to call some file database applications to ensure their databases are up to date with the system. The applications used in the example are (an intrusion detection tool) and  (to use with ), but these are meant as examples. Do not consider this as a guide for AIDE ;-)

To use for this case, we need to "hook" in the   (after removal of files) and   (after installation of files) functions, because that is when the files on the file system have been changed.

La ubicación de /etc/portage/postsync.d
Until now we've talked about hooking into the ebuild processes. However, Portage also has another important function: updating the Portage tree. In order to run tasks after updating the Portage tree, put a script inside and make sure it is marked as executable.

Ejemplo: ejecutar eix-update
If was not used to update the tree, then it is still possible to update the eix database after running  (or ) by putting a symlink to  called  in.

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
When using an NFS-based file systems for rather critical file systems, it might be necessary to mark as a system package, causing Portage to heavily warn administrators if they would attempt to unmerge it.

To accomplish that, we add the package to, prepended with a :

Usando epatch_user
To manage several ebuilds in a similar manner, ebuild developers use eclasses (sort-of shell libraries) that define commonly used functions. One of these eclasses is which offers an interesting function called.

The  function applies source code patches that are found in, whatever directory is found first. Sadly, not all ebuilds automatically call this function so just putting a patch in this location might not always work.

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.

Example: Applying patches to Firefox
The package is one of the many that already call   from within the ebuild, so there is no need to override anything specific.

If for some reason (for instance because a developer provided a patch and asked to check if it fixes the bug reported) patching Firefox is wanted, all that is needed is to put the patch in (probably best to use the full name and version so that the patch does not interfere with later versions) and rebuild Firefox.