Manual Gentoo Linux :Trabajar con Portage
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. Las variables de Portage y lo que significan se describen más adelante.
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.
Al cambiar una variable de configuración, no modifique /usr/share/portage/config/make.globals ni make.defaults. En su lugar, utilice /etc/portage/make.conf, que tiene prioridad sobre los archivos anteriores. Para más información, consulte el archivo /usr/share/portage/config/make.conf.example. Como su nombre indica, este es solo un archivo de ejemplo; Portage no lo lee.
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 se ha nombrado el directorio /etc/portage/make.profile. Este es un enlace simbólico a un perfil; por defecto, uno dentro de /var/db/repos/gentoo/profiles/, aunque se pueden crear perfiles en otros lugares y apuntar a ellos. El perfil al que apunta este enlace simbólico es el perfil al que se adhiere el 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 sea necesario cambiar el comportamiento de Portage, habrá que modificar ciertos archivos dentro de /etc/portage/. Se recomienda encarecidamente usar archivos dentro de /etc/portage/; se desaconseja encarecidamente sobrescribir el comportamiento de Portage mediante 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
No es necesario que sean archivos; también pueden ser directorios que contengan uno o más archivos con la configuración correspondiente. Puede encontrar más información sobre el directorio /etc/portage/, junto con una lista completa de los archivos que se pueden crear, en la página del manual de Portage:
user $man portageCambiar la ubicación de archivos y directorios de Portage
Los archivos de configuración mencionados anteriormente no se pueden almacenar en otro lugar; Portage siempre los buscará en esas ubicaciones exactas. Sin embargo, Portage utiliza muchas otras ubicaciones para diversos fines: compilación de paquetes, almacenamiento de código fuente, ubicaciones de repositorios, etc. Todas estas tienen ubicaciones predeterminadas, pero se pueden modificar a gusto del usuario mediante /etc/portage/make.conf.
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.
Sin embargo, este manual no debe usarse como referencia: para obtener más detalles, consulte las páginas del manual portage y make.conf:
user $man portage
user $man make.conf
Almacenamiento de archivos
El repositorio de ebuilds de Gentoo
La ubicación predeterminada del repositorio de ebuilds de Gentoo es /var/db/repos/gentoo. . Esta ubicación se define mediante el archivo predeterminado repos.conf, que se encuentra en /usr/share/portage/config/repos.conf. Para modificar la ubicación predeterminada, copie este archivo a /etc/portage/repos.conf/gentoo.conf y cambie la configuración location. Al almacenar el repositorio de ebuilds de Gentoo en otro lugar (modificando esta variable), no olvide cambiar el enlace simbólico /etc/portage/make.profile según corresponda.
Después de cambiar la configuración de location en /etc/portage/repos.conf/gentoo.conf, se recomienda alterar también las siguientes variables en /etc/portage/make.conf, ya que, debido a la forma en que Portage maneja las variables, no notarán el cambio de ubicación: 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.
¡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 se configura PORT_LOGDIR, no se almacenarán registros de compilación en el sistema de registro habilitado (aunque los usuarios pueden recibir algunos registros desde el nuevo elog de soporte).
Portage ofrece un control muy ajustable sobre el registro de sistema mediante el uso de elog:
- PORTAGE_ELOG_CLASSES: Aquí los usuarios pueden definir los tipos de mensajes que se registrarán. El valor de la variable puede ser cualquier combinación separada por espacios de
info,warn,error,logyqa.info: Registra los mensajes "einfo" impresos por un ebuild.warn: Registra los mensajes "ewarn" impresos por un ebuild.error: Registra los mensajes "eerror" impresos por un ebuild.log: Registra los mensajes "elog" encontrados en algunos ebuilds.qa: Registra los mensajes "QA Notice" impresos por un ebuild.
- PORTAGE_ELOG_SYSTEM: Selecciona el o los módulos que procesarán los mensajes de registro. Si se deja vacío, se deshabilita el registro. Se puede usar cualquier combinación separada por espacios de
save,custom,syslog,mail,save_summaryymail_summary. Se debe usar al menos un módulo para usar elog.save: Guarda un registro por paquete en $PORT_LOGDIR/elog, o /var/log/portage/elog si $PORT_LOGDIR no está definido.custom: Pasa todos los mensajes a un comando definido por el usuario en $PORTAGE_ELOG_COMMAND; esto se explicará más adelante. **syslog: Envía todos los mensajes al registrador del sistema instalado.mail: Pasa todos los mensajes a un servidor de correo definido por el usuario en $PORTAGE_ELOG_MAILURI; esto se explicará más adelante. Las funciones de correo de elog requieren >=portage-2.1.1.save_summary: Similar a guardar, pero fusiona todos los mensajes en $PORT_LOGDIR/elog/summary.log, o /var/log/portage/elog/summary.log si $PORT_LOGDIR no está definido.mail_summary: Similar a mail, pero envía todos los mensajes en un solo 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:
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):
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:
PORTAGE_ELOG_MAILSUBJECT="El paquete \${PACKAGE} fue instalado en \${HOST} con algunos mensajes"
Si ha usado enotice con Portage-2.0.*, elimine enotice, ya que es incompatible con elog.
Configuración de Portage
Como se mencionó anteriormente, Portage se puede configurar mediante variables en /etc/portage/make.conf o en uno de los subdirectorios de /etc/portage/. Consulte las páginas de man de make.conf y portage para obtener más información:
user $man make.conf
user $man portageOpciones 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 al comando make y suele configurarse para definir el grado de paralelización utilizado durante la compilación. Puede encontrar información sobre las opciones de make en la página de man make(1).
La variable USE también se utiliza durante la configuración y la compilación; consulte los capítulos anteriores de este manual para obtener más detalles.
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 incluyen --ask, --verbose y --tree.
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 emergeExclusió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 --helpSi 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 a300o 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 niceComportamiento 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 .
/etc/portage/make.confUsar la rama estable# El siguiente valor se establece de forma predeterminada y _no_ necesita definirse explícitamente.
ACCEPT_KEYWORDS=""
Para reducir el riesgo de inestabilidad u otros problemas, se recomienda que los usuarios permanezcan en la rama de software estable en general y solo permitan versiones de prueba de los paquetes caso por caso - consulte la sección "Mezclando estable con pruebas" a continuación.
La rama en pruebas
¡Aquí hay dragones! 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, se recomienda que los usuarios permanezcan en la rama estable, que ha sido probada 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 ~.
/etc/portage/make.confUsar la rama en pruebas# Instruir a Portage para que utilice la rama en pruebas (~) para la arquitectura amd64.
ACCEPT_KEYWORDS="~"
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:
/etc/portage/package.accept_keywordsUsar la rama de pruebas sólo para la aplicación gnumericapp-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:
/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
Los desarrolladores de Gentoo enmascaran paquetes por alguna buena razón. Por lo tanto, los canales de soporte de Gentoo generalmente no admiten paquetes desenmascarados por el usuario, y es probable que las solicitudes de soporte relacionadas con package.unmask o package.mask se ignoren o se marquen como WONTFIX. Tenga mucho 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 junto con (normalmente) la razón del porqué. A continuación, supongamos que un administrador del sistema, a pesar de la razón mencionada en el archivo package.mask (ubicado en /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, se puede desenmascarar agregando exactamente la misma línea en la ubicación package.unmask:
/etc/portage/package.unmaskDesenmascarar una versión en particular de un paquete=mail-client/mutt-2.2.9
Si una entrada en /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-, añada la siguiente línea a package.mask:
/etc/portage/package.maskEnmascarar sys-kernel/gentoo-sources con versiones posterior a>sys-kernel/gentoo-sources-
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-confCuando 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-confquickpkg
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 procpsLos 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.
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 (cf. la página del manual portage(5)) en el archivo /etc/portage/repos.conf/gentoo.conf, que configura el 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:
/etc/portage/make.confDefinir el archivo de exclusionesPORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"
/etc/portage/rsync_excludesExcluir todos los juegosgames-*/*
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 soportadas; téngalo en cuenta.
Añadir ebuilds no oficiales
Crear un repositorio de ebuilds personalizado
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 localrepoAdding 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.
Alternativa: 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_nameA continuación, defina la EAPI utilizada para los perfiles dentro del repositorio:
root #echo '8' > /var/db/repos/localrepo/profiles/eapiIndique 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):
/var/db/repos/localrepo/metadata/layout.confmasters = 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:
/etc/portage/repos.conf/repolocal.conf[repolocal]
location = /var/db/repos/localrepo
Trabajar con múltiples repositorios
Para quienes deseen desarrollar varios repositorios de ebuilds, probar paquetes antes de que lleguen al repositorio de Gentoo o usar ebuilds no oficiales de diversas fuentes, app-eselect/eselect-repository también proporciona herramientas para mantener los repositorios actualizados. Para más detalles, consulte la página Eselect/Repository/es.
Añadir un repositorio con eselect repository
Por ejemplo, para habilitar el repositorio GURU:
root #eselect repository enable guruLa actualización de los repositorios agregados con este método se realizará automáticamente en cada sincronización:
root #emerge --syncSoftware 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 pudiera proporcionar ese software. 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- wh el cual ha sido instalado manualmente, añada la siguiente línea a /etc/portage/profile/package.provided:
/etc/portage/profile/package.providedMarcar gentoo-sources- como instalado manualmentesys-kernel/gentoo-sources-
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
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/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:
/etc/portage/package.envUsar el identificador debug-cflags con el paquete mplayermedia-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).
Portage llama a las llamadas funciones de conexión de fase si están definidas en /etc/portage/bashrc. Estas funciones siguen la convención de nomenclatura pre_phase_name y post_phase_name. Por ejemplo, Portage llamará al conector post_pkg_postinst justo después de llamar a la función de fase pkg_postinst.
Para conectarse al proceso, el entorno Bash puede mirar las variables que siempre están disponibles durante el desarrollo de ebuilds (como CATEGORY, P, PF, etc.). En función de los valores de estas variables, se pueden ejecutar pasos 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 para 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, necesitamos "conectar" en las fases postinst (después de la instalación de archivos) y postrm (después de la eliminación de archivos), porque es entonces cuando se han cambiado los archivos en el sistema de archivos.
/etc/portage/bashrcConectar con las fases postinst y postrmmy_database_update() {
echo ":: Llamar a aide --update para actualizar su base de datos"
aide --update
echo ":: Llamar a updatedb para actualizar sus bases de datos"
updatedb
}
post_pkg_postinst() { my_database_update; }
post_pkg_postrm() { my_database_update; }
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 'sincronizar'), 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-updateSi se elige un nombre diferente, debe ser un guión de comandos que llame a /usr/bin/eix-update. El binario eix analiza cómo se le ha llamado para determinar qué función ejecutar. Si se creó un enlace simbólico que apuntaba a eix, pero no se llamaba 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 configuraciones específicas y 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):
/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.