1.  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 acaso no todas estas características adicionales puede encontrarlas fácilmente leyendo las páginas del manual de Portage:

$ man portage
$ man make.conf

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

1.  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/<identifier>.

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/debug-cflags. El nombre es escogido arbitrariamente, pero por supuesto refleja claramente su razón de ser para que sea obvia en el futuro.

CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

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

media-video/mplayer debug-cflags

1.  Enganchándose en el proceso del emerge

Usando /etc/portage/bashrc y archivos afiliados

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 locate), pero solo como ejemplo. No considere que esto sea un CÓMO 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.

if [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ];
then
  echo ":: Calling aide --update to update its database";
  aide --update;
  echo ":: Calling updatedb to update its database";
  updatedb;
fi

1.  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 árbol Portage. Para ejecutar tareas después de actualizar el árbol Portage, 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.

# ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update

1.  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 *:

*net-fs/nfs-utils

1.  Aplicando parches no normados

Usando epatch_user

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

La función epatch_user aplica parches encontrados en /etc/portage/patches/<category>/<package>[-<version>[-<revision>]] 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) y vuelva a construir firefox.