Manual Gentoo Linux amd64:Trabajar con Portage

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:AMD64/Full/Portage and the translation is 100% complete.


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

Almacenar 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 pre-compilados

Aunque Portage no utilice binarios pre-compilados por defecto, tiene un buen soporte para ellos. Cuando a Portage se le indica que trabaje con paquetes pre-compilados, 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.

Construcción de 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/.

Instalación en el sistema de archivos

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.

Características de registro de acciones (log)

Registro de acciones de los 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 contrucció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, puede aumentar o reducir el valor "nice" con el que ejecuta Portage. El valor de la variable PORTAGE_NICENESS se suma al valor nice actual.

Para más información acerca de valores "nice", vea la página man de 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 que rama de programas va a utilizar en su sistema. Como predeterminada figura la rama estable para su arquitectura, por ejemplo amd64.

ARCHIVO /etc/portage/make.confUsing the stable branch
# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="amd64"

Se recomienda ceñirse a la rama estable. Sin embargo, si el administrador desea ayudar al proyecto Gentoo lanzado software no estable, se puede emplear una rama de pruebas para la arquitectura. En este caso: ~amd64. Tenga cuidado ya que al correr software no estable, puede que se necesite enviar informes de fallos a to https://bugs.gentoo.org si se experimenta algún problema.

La rama de pruebas

Advertencia
Hic sunt dracones! Running software from the testing branch may incur stability issues, imperfect package handling (for instance wrong/missing dependencies), frequent ebuild revisions (resulting in a lot of compiling) or packages that are broken in a other, often unexpected, manner. System administrators who are less comfortable with Gentoo or Linux in general should avoid the testing branch. As noted previously, the Handbook recommends staying with the stable, more thoroughly tested branch.

Si quiere utilizar los programas más recientes, puede considerar utilizar la rama de pruebas. Para que Portage utilice la rama de pruebas, añada un ~ delante de su arquitectura.

ARCHIVO /etc/portage/make.confUsar la rama de pruebas
ACCEPT_KEYWORDS="~amd64"

Por ejemplo, para seleccionar la rama de pruebas para una arquitectura amd64, edite /etc/portage/make.conf y escriba:

La rama de pruebas es exactamente para eso - pruebas. Si un paquete se encuentra en pruebas, eso significa que los desarrolladores creen que funciona, pero no ha sido probado concienzudamente. Podría, perfectamente, ser el primero en descubrir un error en el paquete, en cuyo caso puede rellenar un informe de error para ponerlo en conocimiento de los desarrolladores.

Al cambiar de la rama estable a la de pruebas, verá que muchos paquetes serán actualizados. Tenga en cuenta que, después de pasar a la rama de pruebas, el volver a la rama estable será todo un reto.

Mezclando ramales estable con pruebas

La ubicación package.accept_keywords

Puede pedirle a Portage que le permita utilizar la rama de pruebas para algunos paquetes pero seguir utilizando la rama estable en el resto del sistema. Para realizar esto, añada la categoría del paquete y el nombre si quiere utilizar la rama de pruebas al fichero /etc/portage/package.accept_keywords. Además podría crear un directorio (con este mismo nombre) y situar allí el paquete en un fichero.

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

Probando versiones específicas

Si quiere utilizar una versión específica de algún paquete de la rama de pruebas pero no quiere que Portage utiliza esa rama de pruebas para las siguientes versiones, puede añadir la versión a package.accept_keywords. En este caso se debe utilizar el operador =. También puede introducir un rango de versiones con los operadores <=, <, > or >= .

En cualquier caso, si añade información sobre una versión, debe utilizar un operador. Si lo deja sin información sobre la versión, no puede emplear un operador.

En el siguiente ejemplo indicamos a Portage que acepte gnumeric-1.2.13 aunque ésta se encuentre en la rama de pruebas:

ARCHIVO /etc/portage/package.accept_keywordsPermitir la selección de una versión específica
=app-office/gnumeric-1.2.13

Paquetes enmascarados

La ubicación package.unmask

Importante
Los desarrolladores de Gentoo no darán soporte al empleo de estos paquetes. Por favor, tenga cuidado cuando haga esto. Las peticiones de soporte relacionadas con package.unmask o package.mask puede que no se atiendan.

Cuando un paquete ha sido enmascarado por los desarrolladores de Gentoo y aún así desea utilizarlo a pesar de la razón que se menciona en el fichero package.mask (situado por defecto en /var/db/repos/gentoo/profiles/), añada la versión deseada (normalmente será exactamente la misma línea que hay en el archivo package.mask en el perfil) en el fichero /etc/portage/package.unmask (o en un archivo dentro de ese directorio, si es que es un directorio).

To do so, the system administrator would add the target package version (usually this will be the exact same line from the package.mask file in the profile) to the /etc/portage/package.unmask location.

Por ejemplo, si =net-mail/hotwayd-0.8 está enmascarado, puede desenmascararlo añadiendo exactamente la misma línea en package.unmask:

ARCHIVO /etc/portage/package.unmaskDesenmascarando un paquete/version en particular
=net-mail/hotwayd-0.8
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 en package.unmask.

La ubicación package.mask

Cuando no quiera que Portage instale un paquete en concreto o una versión específica de un paquete en su sistema, puede enmascararlo simplemente añadiendo la línea apropiada a /etc/portage/package.mask (tanto si es un fichero como si es un directorio y se hace en un fichero dentro de él).

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

ARCHIVO /etc/portage/package.maskEnmascarar gentoo-sources con una versión posterior a 6.1.38
>sys-kernel/gentoo-sources-6.1.38





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

etc-update

También se puede utilizar etc-update para instalar los ficheros de configuración. No es tan simple de usar como dispatch-conf, ni dispone de tantas funcionalidades, pero proporciona un método de combinación interactivo y también puede realizar actualizaciones triviales de manera automática.

Sin embargo, al contrario que dispatch-conf, etc-update no conserva las versiones antiguas de los archivos de configuración. Una vez se ha actualizado el fichero, la versión anterior se habrá eliminado de manera permanente. Se debe ser muy cuidadoso ya que utilizar etc-update es sensiblemente menos seguro que dispatch-conf a la hora de mantener los ficheros de configuración antiguos.

root #etc-update

Después de combinar los cambios sencillos, se presentará una lista con los ficheros protegidos que tienen una actualización pendiente. Al final se muestran las opciones posibles:

CÓDIGO Opciones mostradas por etc-update
Por favor, seleccione el fichero a editar introduciendo el número correspondiente.
              (-1 para salir) (-3 para auto-combinar todos los ficheros restantes)
                              (-5 para auto-combinar SIN usar 'mv -i'):

Cuando se introduce -1, etc-update terminará y no continuará con el resto. Si se introduce -3 o -5, todos los ficheros de configuración listados serán sobreescritos con las nuevas versiones. Por tanto es muy importante seleccionar primero los ficheros de configuración que no deben ser automáticamente actualizados. Esto se consigue simplemente indicando el número que aparece a la izquierda del fichero de configuración.

Como ejemplo, seleccionamos el fichero de configuración /etc/pear.conf:

CÓDIGO Actualizar un fichero de configuración concreto
Comienzo de diferencias entre /etc/pear.conf y /etc/._cfg0000_pear.conf
[...]
Fin de diferencias entre /etc/pear.conf y /etc/._cfg0000_pear.conf
(1) Reemplazar el original con la actualización</nowiki>
(2) Borrar la actualización, manteniendo el original inalterado
(3) Combinar interactivamente el original y la actualización
(4) Mostrar de nuevo las diferencias

Ahora puede ver las diferencias entre los dos ficheros. Si cree que el fichero de configuración actualizado puede ser utilizado sin problemas, indique 1. Si cree que el fichero de configuración actualizado no es necesario, o no proporciona ninguna información nueva o útil, indique 2. Si quiere actualizar su fichero de configuración actual de forma interactiva, introduzca 3.

Por ahora, no tiene sentido profundizar más sobre la actualización interactiva. Para completarlo, listaremos los comandos que están disponibles durante la combinación interactiva de ambos ficheros. Son mostradas dos líneas (la original, y la nueva propuesta) y un punto indicativo en el cual puede introducir uno de los comandos siguientes:

CÓDIGO Órdenes disponibles en la combinación interactiva
ed:     Editar usando ambas versiones, cada una decorada con una cabecera.
eb:     Editar usando ambas versiones.
el:     Editar usando la versión de la izquierda.
er:     Editar usando la versión de la derecha.
e:      Editar una nueva versión.
l:      Usar la versión de la izquierda.
r:      Usar la versión de la derecha.
s:      Incluir las líneas comunes sin comentarios.
v:      Incluir las líneas comunes con comentarios.
q:      Salir.

Cuando haya acabado de actualizar los ficheros de configuración importantes, puede actualizar automáticamente el resto. etc-update acabará si no encuentra más ficheros de configuración para actualizar.

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.




Utilizando un subconjunto del repositorio Gentoo

Excluyendo categorías y paquetes

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.

Para que funcione este método, se debe deshabilitar la verificación del manifiesto, lo cual reducirá la seguridad del repositorio. Para deshabilitar esta verificación, bien deshabilite el ajuste USE rsync-verify en sys-apps/portage, bien defina sync-rsync-verify-metamanifest=no en la entrada repos.conf del repositorio 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-*/*

Recuerde que esto puede provocar ciertos problemas con las dependencias, ya que paquetes nuevos y aceptados en su sistema pueden depender de otros excluidos.

Añadiendo Ebuilds no oficiales

Definir un repositorio de ebuild personalizado

Manual creation

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

Then define the EAPI used for the profiles within the repository:

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

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

Optional: Creating a repo using eselect repository

Alternatively, a custom ebuild repository can be quickly created using the eselect repository module (from app-eselect/eselect-repository). In the following example, substitute localrepo with a name of choice:

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

A bare repository named "localrepo" will be made available at /var/db/repos/localrepo.

Trabajando con varias extensiones (overlays)

For those desiring to develop several ebuild repos, test packages before they hit the Gentoo repository, or who want to use unofficial ebuilds from various sources, the app-eselect/eselect-repository package also provides tooling to aid in keeping repositories up to date. See also eselect repository article.

eselect-repository

Por ejemplo, para habilitar el recubrimiento hardened-development:

root #eselect repository enable hardened-development
La actualización de recubrimientos que se han añadido mediante este método se hace de forma natural con:
root #emerge --sync

Software no mantenido por Portage

Utilizando Portage con programas automantenidos

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 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.1.38 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.1.38 como instalado manualmente
sys-kernel/gentoo-sources-6.1.38
Nota
En este archivo se usan las versiones sin un operador =.




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:

user $man portage
user $man make.conf

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.

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

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

root #mkdir /etc/portage/env
ARCHIVO /etc/portage/env/depurar-cflagsVariables específicas para depuración
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

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

ARCHIVO /etc/portage/package.envUsar depurar-cflags con el paquete mplayer
media-video/mplayer depurar-cflags

Enganchándose en el proceso del emerge

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 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 mlocate), pero solo como ejemplo. No considere que esto sea 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

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 repositorio de Gentoo. Para ejecutar tareas después de actualizar el repositorio de Gentoo, 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.

root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update
Nota
Si prefiere usar otro nombre, deberá escribir un guión que llame a /usr/bin/eix-update. El binario eix averigua cómo ha sido llamado y deduce qué función debe ejecutar. Si crea un enlace simbólico a eix que no sea eix-update, no se ejecutará correctamente.

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

ARCHIVO /etc/portage/profile/packagesMarcar nfs-utils como paquete del sistema (system)
*net-fs/nfs-utils

Aplicando parches no normados

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

La función epatch_user aplica parches encontrados en /etc/portage/patches/<categoria>/<paquete>[-<versión>[-<revisión>]] 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 posteriores) y vuelva a construir Firefox.



Warning: Display title "Manual Gentoo Linux amd64:Trabajar con Portage" overrides earlier display title "Manual:AMD64/Todo/Portage".