Manual Gentoo Linux amd64:Trabajar con Portage

Advertencia
Los lectores no deben intentar seguir las instrucciones directamente desde el espacio de nombres Handbook:Parts (¡que es ESTA página!). Las secciones que se muestran a continuación se utilizan como una estructura para transclusión de información en los manuales específicos de las diferentes arquitecturas de procesador y, por lo tanto, carecen de información crítica.

Por favor visite la lista de Manuales para leer instrucciones relevantes para cada arquitectura de procesador.

Archivos de Portage

Directivas de configuración

Portage viene con una configuración predefinida guardada en /usr/share/portage/config/make.globals. Toda la configuración de Portage se realiza a través de variables. A qué variables atiende Portage y que significan se describe un poco después.

Como muchas directivas de configuración varían de unas arquitecturas a otras, Portage también posee algunos archivos de configuración que son parte de perfil. Su perfil está apuntado por el enlace simbólico /etc/portage/make.profile; las configuraciones de Portage se realizan en los archivos make.defaults de su perfil y de todos los perfiles padres. Explicaremos algo más sobre perfiles y el directorio /etc/portage/make.profile más adelante.

Si está pensando en cambiar una variable de configuración, no modifique /usr/share/portage/config/make.globals o make.defaults. En lugar de eso utilice /etc/portage/make.conf el cual tiene preferencia sobre los archivos anteriores. También encontrará /usr/share/portage/config/make.conf.example. Como su propio nombre indica, este archivo es meramente un ejemplo y Portage no lo utilizará con ningún propósito.

También puede definir una variable de configuración para Portage como una variable de entorno, pero no es recomendable.

Información específica del perfil

Ya hemos hablado del directorio /etc/portage/make.profile. Bien, no es exactamente un directorio sino un enlace simbólico a un perfil, por defecto uno perteneciente a /var/db/repos/gentoo/profiles/ aunque también puede crear un perfil en cualquier otro lado y apuntarlo. El perfil al cual apunta el enlace simbólico será el que tenga en cuenta su sistema.

Un perfil contiene información específica para Portage sobre cada arquitectura, tal como una lista de paquetes que pertenecen al sistema correspondiente con ese perfil, una lista de paquetes que no funcionan (o están enmascarados) para ese perfil, etc.

Configuración específica de usuario

Cuando necesite sobreescribir una característica de Portage relativa a la instalación de software, necesitará editar los archivos contenidos en /etc/portage/. ¡Se recomienda encarecidamente que utilice los archivos pertenecientes a /etc/portage/ y está desaconsejada la sobreescritura de estas características con variables de entorno!

Dentro de /etc/portage/ puede crear los siguientes archivos:

• package.mask el cual especifica los paquetes que no quiere que Portage instale en su sistema nunca
• package.unmask especifica los paquetes que quiere que Portage instale a pesar de haber sido desaconsejados por los desarrolladores de Gentoo
• package.accept_keywords especifica los paquetes que quiere que Portage instale a pesar de no haber sido considerados adecuados para su sistema o arquitectura (todavía)
• package.use especifica la lista de ajustes USE que quiere utilizar para unos determinados paquetes sin tener que utilizarlos para todo el sistema

Pero no tienen porque ser archivos; también pueden ser directorios que contengan un archivo por paquete. Podemos obtener más información acerca del directorio /etc/portage/ y una lista completa de archivos que pueden crearse allí en la página man de Portage:

user $man portage

Cambiar la ubicación de archivos y directorios de Portage

Los archivos de configuración mencionados anteriormente no pueden ser guardados en ningún otro sitio, Portage siempre los buscará exactamente en esos lugares. Sin embargo, Portage utiliza otras muchos lugares para varios propósitos: el directorio de compilación, el lugar donde guardar el código fuente, la localización del repositorio Gentoo, ...

Todos estos propósitos tienen unas direcciones predeterminadas muy claras pero puede cambiarlas por las que más le gusten indicándolo en /etc/portage/make.conf. El resto de este capítulo explica los lugares destinados a un propósito especial que utiliza Portage y como puede ser modificada su ubicación en el sistema de archivos.

Este documento no pretende ser utilizado como referencia. Si necesita un conocimiento completo, por favor consulte las páginas man relativas a Portage y make.conf:

user $man portage

user $man make.conf

Almacenamiento de archivos

El repositorio de ebuilds de Gentoo

La ubicación por defecto del repositorio de ebuilds de Gentoo es /var/db/repos/gentoo. Esto se define en el fichero por defecto repos.conf que se encuentra en repos.conf. Para modificar el valor por defecto, copie este fichero a /etc/portage/repos.conf/gentoo.conf y cambie el ajuste location. Cuando se almacene el repositorio de ebuilds de Gentoo en otro lugar (cambiando el valor de esta variable), no olvide cambiar el enlace simbólico /etc/portage/make.profile de forma apropiada.

Después de cambiar el valor del ajuste location en /etc/portage/repos.conf/gentoo.conf, se recomienda alterar igualmente las siguientes variables en /etc/portage/make.conf ya que no reflejarán el cambio realizado en location. Esto es debido a cómo Portage gestiona estas variables: PKGDIR, DISTDIR y RPMDIR.

Binarios precompilados

Aunque Portage no utiliza binarios precompilados de forma predeterminada, cuenta con un amplio soporte para ellos. Cuando se le pide a Portage que trabaje con paquetes precompilados, los buscará en /var/cache/binpkgs. Esta ubicación está definida por la variable PKGDIR.

Código fuente

El código fuente de las aplicaciones se guarda por defecto en /var/cache/distfiles. Esta ubicación viene definida por la variable DISTDIR.

Base de datos de Portage

Portage guarda el estado del sistema (que paquetes están instalados, qué archivos pertenecen a cada paquete, ...) en /var/db/pkg.

Advertencia
¡No modificar los ficheros de estado del sistema manualmente!. Podría romper el conocimiento que tiene Portage sobre el sistema.

Caché de Portage

La caché de Portage (con fechas de modificacion, paquetes virtuales, información del árbol de dependencias, ...) se guarda en /var/cache/edb. Esta ubicación es una caché real: se puede borrar si no se está ejecutando ninguna aplicación que tenga relación con Portage en este momento.

Construir aplicaciones

Archivos temporales de Portage

Los archivos temporales de portage se guardan por defecto en /var/tmp/. Esta ubicación se define en la variable PORTAGE_TMPDIR.

Directorio de construcción

Portage crea directorios de compilación específicos dentro de /var/tmp/portage/ para cada paquete que emerge . Esta ubicación viene definida por la variable PORTAGE_TMPDIR añadiendo portage/.

Ubicación del sistema de archivos live

Por defecto, Portage instala todas los archivos en el sistema de ficheros activo (/), pero puede cambiarse esta configuración a través de la variable de entorno ROOT. Esto es útil cuando quiera crear nuevas imágenes compiladas.

Funciones de registro

Registro de ebuilds

Portage puede crear un registro por ebuild, pero solamente cuando la variable PORT_LOGDIR esté configurada y apuntando a una dirección con permisos de escritura para Portage (usuario Portage). De manera predeterminada está variable está desactivada. Si no configura PORT_LOGDIR no recibirá los registros con el sistema de registro actual, aunque tal vez reciba algún registro del nuevo sistema elog.

Si no tiene definido PORT_LOGDIR y usa elog, recibirá los registros de construcción de paquetes y cualquier otro registro guardado por elog, como se explica a continuación.

Portage ofrece un control muy ajustable sobre el registro de sistema mediante el uso de elog:

• PORTAGE_ELOG_CLASSES: Es donde se define cqué tipo de mensajes serán registrados. Puede utilizarse cualquier cualquier combinación separada por espacios en blanco de info, warn, error, log y qa.
  • info: Registra los mensajes "einfo" generados por un ebuild
  • warn: Registra los mensajes "ewarn" generados por un ebuild
  • error: Registra los mensajes "eerror" generados por un ebuild
  • log: Registra los mensajes "elog" que se pueden encontrar en algunos ebuilds
  • qa:: Registra los mensajes del tipo "QA Notice" generados por un ebuild

• PORTAGE_ELOG_SYSTEM: Selecciona el módulo o módulos para procesar los mensajes de registro. Si se deja sin definir, se desactiva la función de registro. Puede usar cualquier combinación separada por espacios en blanco de save, custom, syslog, mail, save_summary y mail_summary. Debe seleccionar al menos un módulo para poder usar elog.
  • save: Almacena un registro por paquete en $PORT_LOGDIR/elog, o /var/log/portage/elog si $PORT_LOGDIR no está definida.
  • custom: Pasa todos los mensajes a una orden definida por el usuario en $PORTAGE_ELOG_COMMAND; se detalla más adelante.
  • syslog: Envía todos los mensajes al gestor de registro de sistema instalado.
  • mail: Pasa todos los mensaje a un servidor de correo definido por el usuario en $PORTAGE_ELOG_MAILURI; se detalla más adelante. Las características de correo de elog requieren un portage >=portage-2.1.1.
  • save_summary: parecido a save, pero fusionando todos los mensajes en $PORT_LOGDIR/elog/summary.log, o /var/log/portage/elog/summary.log si $PORT_LOGDIR fue definida.
  • mail_summary: parecido a mail, pero envía todos los mensajes en un solo mensaje de correo cuando emerge finaliza.

• PORTAGE_ELOG_COMMAND: Esto solamente se usa al activarse el módulo custom. Aquí podemos especificar una orden con la cual se procesarán los mensajes de registro. Observe que puede hacer uso de dos variables de entorno: ${PACKAGE} es el nombre del paquete y la versión, mientras que ${LOGFILE} es la ruta absoluta del archivo de registro. A continuación se muestra un posible uso:

CÓDIGO Ejemplo de definición de PORTAGE_ELOG_COMMAND

PORTAGE_ELOG_COMMAND="/ruta/al/ejecutable/registrador -p '\${PACKAGE}' -f '\${LOGFILE}'"

• PORTAGE_ELOG_MAILURI: Contiene la configuración del módulo mail, tal como dirección, usuario, contraseña, servidor de correo y número de puerto. Por defecto está configurado a "root@localhost localhost". Aquí presentamos un ejemplo para un servidor SMTP que requiere autenticación con nombre de usuario y contraseña en un puerto en particular (el puerto por defecto es el 25):

CÓDIGO Ejemplo de definición de PORTAGE_ELOG_MAILURI

PORTAGE_ELOG_MAILURI="usuario@algun.dominio
usuario:password@smtp.algun.dominio:995"

• PORTAGE_ELOG_MAILFROM: Permite configurar la dirección "from" de los correos de registro; su valor por defecto es "Portage".

• PORTAGE_ELOG_MAILSUBJECT: Permite la creación de una línea de asunto para los correos de registro. Note que puede hacer uso de dos variables de entorno: ${PACKAGE} mostrará el nombre y la versión del paquete, mientras que ${HOST} es el nombre del dominio completo del anfitrión donde está corriendo Portage. Aquí está un posible uso:

CÓDIGO Ejemplo de definición de PORTAGE_ELOG_MAILSUBJECT

PORTAGE_ELOG_MAILSUBJECT="El paquete \${PACKAGE} fue instalado en \${HOST} con algunos mensajes"

Importante
Si ha usado enotice con Portage-2.0.*, elimine enotice, ya que es incompatible con elog.

Configuración de Portage

Como hemos indicado previamente, Portage se puede configurar mediante múltiples variables de entorno que se deben definir en /etc/portage/make.conf o en uno de los subdirectorios de /etc/portage/. Por favor, eche un vistazo a las páginas del manual de make.conf y portage para obtener información detallada:

user $man make.conf

user $man portage

Opciones específicas para la construcción de aplicaciones

Opciones de configuración y del compilador

Cuando Portage construye las aplicaciones, pasa el contenido de las siguientes variables al guión de compilación y configuración:

CFLAGS y CXXFLAGS

Define los parámetros deseados para la compilación de fuentes en C y C++

CHOST

Define la plataforma correspondiente a la máquina en la que se construye para el guión de configuración

MAKEOPTS

Se pasa a la orden make para definir el grado de paralelismo al compilar. Para más información acerca de sus opciones, vea la página man de make.

La variable USE también se usa al configurar y compilar, pero éste ha sido explicado ampliamente en capítulos previos.

Opciones al integrar

Cuando Portage integra una versión más nueva de algún paquete de software, también eliminará los archivos obsoletos de la versión anterior del sistema. Portage otorga un tiempo de gracia de 5 segundos al usuario antes de llevar esta tarea a cabo. Este tiempo se define por medio de la variable CLEAN_DELAY.

Puede decirle a emerge que use ciertas opciones cada vez que sea ejecutado configurando la variable EMERGE_DEFAULT_OPTS. algunas opciones útiles podrían ser --ask, --verbose, --tree, etc.

Protección de los archivos de configuración

Ubicaciones protegidas por Portage

Portage sobreescribe los archivos proporcionados por versiones más nuevas de un paquete si estos no estan almacenados en un lugar protegido. Estos lugares protegidos se definen con la variable CONFIG_PROTECT y generalmente corresponden a rutas de archivos de configuración. Este listado de directorios es delimitado con espacios en blanco.

Los archivos de configuración nuevos que se escriban en rutas protegidas lo serán con un nombre modificado y el usuario será advertido acerca de su presencia.

Puede averiguar qué lugares están protegidos en la variable CONFIG_PROTECT con la salida de la orden emerge --info:

user $emerge --info | grep 'CONFIG_PROTECT='

Más información acerca de la protección de archivos de configuración por Portage está disponible en la sección de archivos de configuración (CONFIGURATION FILES) de la página man de emerge:

user $man emerge

Exclusión de directorios

Para 'desproteger' ciertos subdirectorios en directorios protegidos, use la variable CONFIG_PROTECT_MASK.

Opciones de descarga

Ubicaciones de servidores

Cuando la información o datos no están disponibles en su sistema, Portage los descargará de Internet. Las ubicaciones de los servidores para los canales de información y datos se definen mediante los siguientes variables:

GENTOO_MIRRORS

Define una lista de servidores que contienen código fuente (distfiles)

PORTAGE_BINHOST

Define un servidor en particular que contiene paquetes pre-compilados para su sistema

Un tercer ajuste involucra la ubicación del servidor rsync utilizado al actualizar el repositorio local de Gentoo. Esto se define en el fichero /etc/portage/repos.conf (o en un fichero dentro de ese directorio si se ha definido como tal):

sync-type

Define el tipo de servidor y su valor por defecto es rsync

sync-uri

Define un servidor en particular que Portage utiliza para recuperar el repositorio de Gentoo.

Las variables GENTOO_MIRRORS, sync-type y sync-uri se pueden definir automáticamente mediante la orden mirrorselect. Debe hacer emerge app-portage/mirrorselect antes de usarla. Para más información, vea la ayuda de mirrorselect en línea:

root #mirrorselect --help

Si su entorno requiere el uso de un servidor proxy, configure las variables http_proxy, ftp_proxy y RSYNC_PROXY para declararlos.

Órdenes para descargar

Cuando Portage requiera descargar fuentes, utiliza por defecto la orden wget. Puede cambiar esto usando la variable FETCHCOMMAND.

Portage puede continuar una descarga hecha en forma parcial. Usa wget por defecto, pero puede cambiarlo usando la variable RESUMECOMMAND.

Asegúrese que sus FETCHCOMMAND y RESUMECOMMAND guarde las fuentes en la ubicación correcta. Al definir las variables debe usar \${URI} y \${DISTDIR} para apuntar a la ubicación de las fuentes y la ubicación del directorio distfiles respectivamente.

Puede definir manejadores específicos por protocolo con FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, etc.

Configuración de rsync

Aunque no se puede alterar la orden rsync usada para actualizar el repositorio de Gentoo, podrá configurar algunas de las variables para modificar su comportamiento:

PORTAGE_RSYNC_OPTS

Configura un número de variables por defecto usadas durante la sincronización, separado por espacios en blanco. Estos no deberían ser cambiados a no ser que sepa exactamente lo que está haciendo. Note que ciertas opciones requeridas con obligatoriedad serán siempre usadas aunque PORTAGE_RSYNC_OPTS no tenga valor asignado.

PORTAGE_RSYNC_EXTRA_OPTS

Usada para configurar opciones adicionales al sincronizar. Cada opción deberá ser separada con un espacio en blanco.

--timeout=<número>

define la cantidad de segundos que una conexión rsync puede permanecer sin que caduque. Esta variable tiene un valor por defecto 180, pero los usuarios con conexiones vía telefónica o individuos con ordenadores lentos podrían aumentar a 300 o más.

--exclude-from=/etc/portage/rsync_excluir

Esto apunta a un archivo que lista los paquetes y/o categorías que rsync debe ignorar durante el proceso de actualización. En este caso, apunta a /etc/portage/rsync_excluir.

--quiet

Reduce la cantidad de información que sale por pantalla

--verbose

Muestra una lista completa de archivos

--progress

Muestra un medidor de progreso por cada archivo

PORTAGE_RSYNC_RETRIES

Define la cantidda de veces que rsync debe intentar conectar con el servidor apuntado por la variable SYNC variable antes de abandonar. Por defector, esta variable es 3.

Para mas información sobre estas y otras opciones, lea man rsync.

Configuración de Gentoo

Selección de rama

Puede escoger su rama por defecto a través de la variable ACCEPT_KEYWORDS. El valor por defecto es la rama estable de su plataforma. Para más información acerca de las ramas de Gentoo, vea el capítulo siguiente.

Características de Portage

Puede activar ciertas características de Portage por medio de la variable FEATURES. Estas han sido discutidas en capítulos anteriores.

Comportamiento de Portage

Gestión de los recursos

Con la variable PORTAGE_NICENESS, los usuarios pueden aumentar o reducir el valor nice que Portage utilizará durante su ejecución. El valor PORTAGE_NICENESS se agrega al valor nice actual de Portage.

Para obtener más información sobre los valores nice, consulte Portage niceness y la página del manual nice:

user $man nice

Comportamiento de la salida

El valor de NOCOLOR, que por defecto es false, define si Portage desactiva el uso de los colores en su salida.

Utilizando una sola rama

La rama estable

La variable ACCEPT_KEYWORDS define la rama de software del sistema. Esta variable se establece en el archivo /etc/portage/make.conf y está configurada en la rama estable de manera predeterminada. En este caso, el valor predeterminado es amd64.

ARCHIVO /etc/portage/make.confUsar la rama estable

# El siguiente valor se establece de forma predeterminada y _no_ necesita definirse explícitamente.
ACCEPT_KEYWORDS="amd64"

Para una experiencia más agradable y con menos riesgo de inestabilidad u otros problemas, el Manual recomienda permanecer en la rama de software estable. Dado que este es el comportamiento predeterminado de Portage, no es necesario realizar cambios. Los administradores de sistemas que quieran vivir con cierto riergo o recibir las últimas actualizaciones de software posibles deben leer la sección en pruebas section.

La rama en pruebas

Advertencia
¡Hic sunt dracones! Ejecutar software desde la rama en pruebas puede generar problemas de estabilidad, manejo erróneo de paquetes (por ejemplo, dependencias incorrectas o faltantes), revisiones frecuentes de ebuild (que se traducen en una gran cantidad de compilación) o paquetes que fallan de alguna otra manera, a menudo inesperada. Los administradores de sistemas que no se sientan cómodos con Gentoo o Linux en general deberían evitar la rama en pruebas. Como se indicó anteriormente, el Manual recomienda quedarse con la rama estable, que se ha probado más exhaustivamente.

En los casos en los que el administrador del sistema desee ejecutar un conjunto de software menos probado y, a cambio, recibir actualizaciones de última generación, se puede seleccionar la rama en pruebas. Para cambiar a la rama en pruebas, configure el valor ACCEPT_KEYWORDS en ~amd64.

ARCHIVO /etc/portage/make.confUsar la rama en pruebas

# Instruir a Portage para que utilice la rama en pruebas (~) para la arquitectura amd64.
ACCEPT_KEYWORDS="~amd64"

Cualquier arquitectura soportada por el proyecto Gentoo puede moverse a una rama en pruebas simplemente agregando un ~ (símbolo tilde) delante del valor ACCEPT_KEYWORDS de la arquitectura.

La rama en pruebas es exactamente lo que uno esperaría: inestable. Si un paquete está en pruebas, significa que los desarrolladores creen que es funcional pero no se ha probado a fondo. Los sistemas que utilizan la rama en pruebas pueden ser los primeros en encontrar errores en el paquete. Si se descubren errores, envíe un informe de errores para informar al desarrollador.

Al cambiar de la rama estable a la en pruebas y realizar una actualización de @world, es normal que muchos paquetes (a veces cientos) se actualicen a las últimas versiones disponibles. Las actualizaciones generalmente corresponden a la versión actual del proyecto original. Tenga en cuenta que, después de pasar de la rama estable a la de pruebas, puede resultar un desafío volver a la rama estable. Esto es de esperar.

Mezclar las ramas estable y pruebas

package.accept_keywords

Es posible indicarle a Portage que permita la rama en pruebas para paquetes específicos, pero que utilice la rama estable para el resto del sistema. Para lograr esto, agregue la categoría y el nombre del paquete en el archivo /etc/portage/package.accept_keywords. También es posible crear un "directorio" (con el mismo nombre) y enumerar el paquete en un archivo debajo del directorio.

Por ejemplo, para utilizar la rama de pruebas con gnumeric:

ARCHIVO /etc/portage/package.accept_keywordsUsar la rama de pruebas sólo para la aplicación gnumeric

app-office/gnumeric

Probar versiones específicas

Para utilizar una versión de software específica de la rama en pruebas pero no permitir actualizaciones de la rama en prueba para versiones posteriores, se puede definir una versión específica del paquete en el archivo package.accept_keywords. Para definir una versión específica, se utiliza el operador =. También es posible ingresar un rango de versiones utilizando los operadores <=, <, > o >=.

En cualquier caso, si se define información sobre la versión de un paquete, se debe utilizar un operador. Sin información sobre la versión, no se puede utilizar el operador.

A continuación se le indica a Portage que permita la instalación de una versión específica de gnumeric, la versión 1.2.13, incluso si está en la rama en pruebas:

ARCHIVO /etc/portage/package.accept_keywordsPermitir la selección de una versión específica del paquete gnumeric

=app-office/gnumeric-1.2.13

Paquetes enmascarados

package.unmask

Importante
Los desarrolladores de Gentoo enmascaran los paquetes por una buena razón, por lo tanto desenmascarar un paquete, normalmente, no tendrá soporte de Gentoo en los canales de soporte. Por esta razón, es de esperar que las solicitudes de soporte relacionadas con package.unmask y/o package.mask sean ignoradas o marcadas como WONTFIX. Por favor, tenga cuidado al desenmascarar paquetes.

Para el siguiente ejemplo, supongamos que los desarrolladores de Gentoo han enmascarado un paquete. Al intentar instalar el paquete, Portage mostrará un mensaje indicando que el paquete ha sido enmascarado y generalmente proporcionará una razón para ello. A continuación, supongamos que un administrador del sistema, a pesar de la razón mencionada en el archivo package.mask (ubicado en /var/db/repos/gentoo/profiles/ de forma predeterminada), aún desea instalar el paquete.

Para hacerlo, el administrador del sistema agregaría la versión del paquete en concreto (generalmente será exactamente la misma línea del archivo package.mask en el perfil) a la ubicación /etc/portage/package.unmask.

Por ejemplo, si =mail-client/mutt-2.2.9 está enmascarado (¡pobrecillo!), se puede desenmascarar agregando exactamente la misma línea en la ubicación package.unmask:

ARCHIVO /etc/portage/package.unmaskDesenmascarar una versión en particular de un paquete

=mail-client/mutt-2.2.9

Nota
Si una entrada en /var/db/repos/gentoo/profiles/package.mask contiene un rango de versiones de paquete, necesitará desenmascarar únicamente la versión o versiones que realmente necesita. Por favor, lea la sección previa para aprender cómo especificar versiones usando operadores.

package.mask

También es posible indicarle a Portage que no instale un determinado paquete o que no actualice a una versión específica de un paquete. Esto se denomina enmascarar un paquete. Para enmascarar un paquete, agregue calificadores según sea necesario a la ubicación /etc/portage/package.mask (ya sea en ese archivo o en un archivo de este directorio).

Por ejemplo, si no quiere que Portage instale otras fuentes del núcleo mas actuales a gentoo-sources-6.6.21, añada la siguiente línea a package.mask:

ARCHIVO /etc/portage/package.maskEnmascarar sys-kernel/gentoo-sources con versiones posterior a 6.6.21

>sys-kernel/gentoo-sources-6.6.21

dispatch-conf

dispatch-conf es una herramienta diseñada para combinar los archivos ._cfg0000_<nombre>. Los archivos ._cfg0000_<nombre> son generados por Portage cuando intenta sobreescribir un archivo en un directorio protegido por la variable CONFIG_PROTECT.

Empleando dispatch-conf, se puede actualizar la configuración mientras se registran todos los cambios realizados. dispatch-conf guarda las diferencias entre las distintas configuraciones como parches o utilizando el sistema de control de versiones RCS. Esto implica que, si se comete un error en la actualización de un archivo de configuración, se puede regresar a la versión anterior del archivo en cualquier momento.

Cuando se utiliza dispatch-conf, se le puede indicar que deje el archivo de configuración tal cual, que utilice la nueva configuración, que permita editar la configuración actual o que combine los cambios interactivamente. dispatch-conf además dispone de algunas funcionalidades adicionales:

• Automáticamente actualizar el fichero de configuración si las actualizaciones solamente afectan a comentarios.
• Automáticamente actualizar los ficheros de configuración que sólo difieren en la cantidad de espacios en blanco.

Hay que asegurarse de primero editar /etc/dispatch-conf.conf y crear el directorio al que hace referencia la variable archive-dir. Después, ejecutar dispatch-conf:

root #dispatch-conf

Cuando se ejecuta dispatch-conf, cada fichero con cambios será procesado, uno por uno. Pulse u para actualizar (reemplazar) el fichero actual por el nuevo y continuar con el siguiente. Pulse z para omitir (borrar) el nuevo fichero de configuración y continuar con el siguiente. La tecla n no le indicará a dispatch-conf que debe saltar al siguiente fichero. Esto se puede realizar para demorar una mezcla que se va a realizar en el futuro. Una vez que se hayan procesado todos los ficheros, dispatch-conf terminará. También se puede pulsar q en cualquier momento para salir de la aplicación.

Para más información, consulte la página man de dispatch-conf. Allí se detalla como combinar interactivamente los de configuración actuales y los nuevos, editar nuevos archivos de configuración, comprobar las diferencias entre archivos y mucho más.

user $man dispatch-conf

quickpkg

Con quickpkg se pueden crear archivos de paquetes que ya han sido instalados en el sistema. Estos archivos pueden usarse como paquetes precompilados. Ejecutar quickpkg es sencillo: basta añadir los nombres de los paquetes que se quiere archivar.

Por ejemplo, para archivar curl, orage y procps:

root #quickpkg curl orage procps

Los paquetes precompilados se almacenarán en $PKGDIR (por defecto /var/cache/binpkgs/). Los paquetes serán ubicados en $PKGDIR/CATEGORY.

Utilizar un subconjunto del repositorio Gentoo

Excluir paquetes y categorías

Puede realizar una actualización selectiva de ciertas categorías/paquetes e ignorar el resto. Esto se realiza indicando a rsync que excluya categorías/paquetes durante el proceso emerge --sync.

Advertencia
Para que este método funcione, la verificación del manifiesto debe estar deshabilitada. Esto reducirá la seguridad del repositorio. Para deshabilitar la verificación, deshabilite el indicador USE rsync-verify en el paquete sys-apps/portage o configure sync-rsync-verify-metamanifest=no (consulte man 5 portage) en la línea de repos.conf correspondiente al repositorio de ebuilds de Gentoo.

Necesita definir el nombre del archivo que contiene los patrones de exclusión en la variable PORTAGE_RSYNC_EXTRA_OPTS de su /etc/portage/make.conf:

ARCHIVO /etc/portage/make.confDefinir el archivo de exclusiones

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

ARCHIVO /etc/portage/rsync_excludesExcluir todos los juegos

games-*/*

Advertencia
Excluir partes de los repositorios de ebuilds, especialmente en el repositorio de ebuild de Gentoo, puede generar problemas de dependencias. Los paquetes nuevos permitidos pueden depender de paquetes nuevos pero excluidos. Las exclusiones no son compatibles, proceda teniendo en cuenta este riesgo.

Añadir ebuilds no oficiales

Crear un repositorio de ebuilds personalizado

Creación manual

Es posible instruir a Portage para que utilice ebuilds que no están oficialmente disponibles a través del repositorio de ebuilds de Gentoo. Para hacerlo, cree un nuevo directorio (por ejemplo, /var/db/repos/localrepo) en el que almacenar los ebuilds de terceros. Este nuevo repositorio requerirá la misma estructura de directorios que el repositorio oficial de Gentoo.

root #mkdir -p /var/db/repos/localrepo/{metadata,profiles}

root #chown -R portage:portage /var/db/repos/localrepo

A continuación, elija un nombre significativo para el repositorio. El siguiente ejemplo usa "repolocal" como nombre:

root #echo 'localrepo' > /var/db/repos/localrepo/profiles/repo_name

A continuación, defina la EAPI utilizada para los perfiles dentro del repositorio:

root #echo '8' > /var/db/repos/localrepo/profiles/eapi

Indique a Portage que el repositorio maestro es el repositorio principal de ebuilds de Gentoo, y que el repositorio local no debe sincronizarse automáticamente (ya que no está respaldado por una fuente externa como un servidor rsync, servidor espejo git u otro tipo de repositorio):

ARCHIVO /var/db/repos/localrepo/metadata/layout.conf

masters = gentoo
auto-sync = false
thin-manifests = true
sign-manifests = false

Finalmente, hay que habilitar el repositorio para el sistema local creando un archivo de configuración de repositorio dentro de /etc/portage/repos.conf. Esto informará a Portage dónde se puede localizar nuestro repositorio personalizado:

ARCHIVO /etc/portage/repos.conf/repolocal.conf

[repolocal]
location = /var/db/repos/localrepo

Opcional: Crear un repositorio usando eselect repository

Como alternativa, se puede crear rápidamente un repositorio de ebuilds personalizado utilizando el módulo de repositorio de eselect (desde app-eselect/eselect-repository). En el siguiente ejemplo, sustituya localrepo por un nombre de su elección:

root #eselect repository create localrepo

Adding localrepo to /etc/portage/repos.conf/eselect-repo.conf ...
Repository <ebuild_repository_name> created and added

Un repositorio vacío llamado "localrepo" estará disponible en /var/db/repos/localrepo.

Trabajar con múltiples repositorios

Para quienes deseen desarrollar varios repositorios de ebuild, probar paquetes antes de que lleguen al repositorio Gentoo o quieran usar ebuilds no oficiales de varias fuentes, el paquete app-eselect/eselect-repository también proporciona herramientas para ayudar a mantener los repositorios actualizados. Consulte también el artículo sobre eselect repository.

Añadir un repositorio con eselect repository

Por ejemplo, para habilitar el repositorio GURU:

root #eselect repository enable guru

La actualización de los repositorios agregados con estos métodos se realizará automáticamente en cada sincronización:

root #emerge --sync

Software no mantenido por Portage

Usar Portage con programas auto-mantenidos

En algunos casos querrá configurar, instalar y mantener programas por sí mismo sin que Portage automatice el proceso, incluso aunque Portage pueda suministrarle esos programas. Conocidos son los casos de paquetes como las fuentes del núcleo y los controladores de Nvidia. Puede configurar Portage para que conozca cuando un determinado paquete ha sido instalado manualmente en el sistema. Este proceso recibe el nombre de inyectar y está soportado por Portage a través del archivo /etc/portage/profile/package.provided.

Por ejemplo, si quiere informar a Portage sobre gentoo-sources-6.6.21 wh el cual ha sido instalado manualmente, añada la siguiente línea a /etc/portage/profile/package.provided:

ARCHIVO /etc/portage/profile/package.providedMarcar gentoo-sources-6.6.21 como instalado manualmente

sys-kernel/gentoo-sources-6.6.21

Nota
En este archivo se usan las versiones sin un operador =.

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

ARCHIVO /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:

ARCHIVO /etc/portage/package.envUsar el identificador debug-cflags con el paquete mplayer

media-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).

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.

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

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-update

Nota
Si 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):

ARCHIVO /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.