This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Gentoo Linux Manual de Gentoo: Trabajar con Portage
No intente seguir las instrucciones directamente desde la ruta Manual de Gentoo:Partes (o cualquiera de sus páginas subordinadas). Manual de Gentoo:Partes es un meta-Manual de Gentoo utilizando para producir el texto. Utilice en su lugar los manuales específicos de cada arquitectura que pueden encontrar en el listado de Manuales de Gentoo.
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.
Since many configuration directives differ between architectures, Portage also has default configuration files which are part of the system profile. This profile is pointed to by the /etc/portage/make.profile symlink; Portage's configurations are set in the make.defaults files of the profile and all parent profiles. We'll explain more about profiles and the /etc/portage/make.profile directory later on.
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 /usr/portage/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 portageCambiar 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.confEl almacén de archivos
El repositorio Gentoo
The default location of the Gentoo ebuild repository is at /usr/portage. This is defined by the default repos.conf file found at /usr/share/portage/config/repos.conf. To modify the default, copy this file to /etc/portage/repos.conf/gentoo.conf and change the location setting. When storing the Gentoo ebuild repository elsewhere (by altering this variable), don't forget to change the /etc/portage/make.profile symbolic link accordingly.
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 /usr/portage/packages. Esta ubicación está definida por la variable PKGDIR.
Código Fuente
El código fuente de las aplicaciones se guarda por defecto en /usr/portage/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 se deben modificar estos archivos 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 BUILD_PREFIX.
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:
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 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 portageOpciones 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 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, 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 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 que rama de programas va a utilizar en su sistema. Como predeterminada figura la rama estable para su arquitectura, por ejemplo .
Recomendamos que solamente utilice la rama estable. Sin embargo si no le importa demasiado la estabilidad y quiere ayudar a Gentoo a través del envío de informes de error a https://bugs.gentoo.org entonces puede usar la rama de pruebas.
La rama de pruebas
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.
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.
Tenga cuidado; al usar la rama de pruebas se pueden experimentar problemas de estabilidad, gestión imperfecta del paquete (por ejemplo dependencias erróneas), actualizaciones demasiado frecuentes (que dan cómo resultado múltiples compilaciones) o paquetes que no funcionan. Si no se conoce cómo funciona Gentoo y como resolver los problemas, recomendamos que se quede con la rama probada y estable.
Por ejemplo, para seleccionar la rama de pruebas para una arquitectura , edite /etc/portage/make.conf y escriba:
/etc/portage/make.confUsar la rama de pruebasACCEPT_KEYWORDS="~"
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:
/etc/portage/package.accept_keywordsUsar la rama de pruebas sólo para la aplicación gnumericapp-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:
/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
The Gentoo developers do not support the use of unmasking packages. Please exercise due caution when doing so. Support requests related to package.unmask and/or package.mask might not be answered.
When a package has been masked by the Gentoo developers, yet despite the reason mentioned in the package.mask file (situated in /usr/portage/profiles/ by default) a user still wants to use this package, then add the desired version (usually this will be the exact same line from the package.mask file in the profile) to the /etc/portage/package.unmask file (or in a file in that directory if it is a directory).
For instance, if =net-mail/hotwayd-0.8 is masked, then it can be unmasked by adding the exact same line in the package.unmask location:
/etc/portage/package.unmaskDesenmascarando un paquete/version en particular=net-mail/hotwayd-0.8
Si una entrada en /usr/portage/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).
For instance, to prevent Portage from installing kernel sources newer than gentoo-sources-, add the following line at the package.mask location:
/etc/portage/package.maskEnmascarar el paquete gentoo-sources con versión mayor que 2.6.8.1>sys-kernel/gentoo-sources-2.6.8.1
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-confetc-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-updateDespué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:
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:
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:
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 procpsLos paquetes precompilados se almacenarán en $PKGDIR (por defecto /usr/portage/packages/). 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.
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-*/*
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
Definiendo un repositorio personalizado
Puede indicarle a Portage que utilice ebuilds que no están disponibles oficialmente a través del repositorio Gentoo. Cree un nuevo directorio (por ejemplo /usr/local/portage) en el cual guardará los ebuilds procedentes de otras fuentes. ¡Utilice la misma estructura de directorios del repositorio Gentoo oficial!
root #mkdir -p /usr/local/portage/{metadata,profiles}
root #chown -R portage:portage /usr/local/portageA continuación, elija un nombre significativo para el repositorio. El siguiente ejemplo usa "repolocal" como nombre:
root #echo 'repolocal' > /usr/local/portage/profiles/repo_nameInformar a Portage que el repositorio de referencia es el repositorio Gentoo principal y que nuestro repositorio personalizado no se debe sincronizar automáticamente (ya que no está respaldado por ningún servidor rsync, servidor git espejo ni ningún otro repositorio fuente):
/usr/local/portage/metadata/layout.confmasters = 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, para informar a Portage dónde se puede localizar nuestro repositorio personalizado.
/etc/portage/repos.conf/repolocal.conf[repolocal] location = /usr/local/portage
Trabajando con varias extensiones (overlays)
Para los usuarios que desarrollan en varias extensiones, probar los paquetes antes de que lleguen al repositorio Gentoo o simplemente que quieren utilizar ebuilds no oficiales procedentes de varias fuentes, el paquete app-portage/layman incorpora layman, una herramienta que ayudará a conservar las extensiones actualizadas.
Alternatively, install app-eselect/eselect-repository to utilize the native synchronization in Portage. See also Eselect/Repository
eselect-repository
Adding repositories is simple with this tool.
For instance, to enable the hardened-development overlay:
root #eselect repository enable hardened-developmentUpdating of overlays added with this methods happens naturally with:
root #emerge --syncEn primer lugar, instale y configure layman como se muestra en la Guía de Usuario de Overlays, y añada los repositorios que desee con layman -a.
Por ejemplo, para habilitar la extensión hardened-development:
root #layman -a hardened-developmentIndependientemente de cuantas extensiones use con layman, todos los repositorios pueden actualizarse con la siguiente orden:
root #layman -SPara más información sobre el trabajo con extensiones, por favor, lea man layman y la Guía de usuario de layman/overlay del enlace antes mencionado.
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- 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
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.
/etc/portage/env/depurar-cflagsVariables específicas para depuraciónCFLAGS="-O2 -ggdb -pipe" FEATURES="${FEATURES} nostrip"
Luego agregamos el rótulo al paquete media-video/mplayer para usar su contenido:
/etc/portage/package.envUsar depurar-cflags con el paquete mplayermedia-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.
/etc/portage/bashrcHooking into the postinst and postrm phasesif [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ]; then echo ":: Calling aide --update to update its database" aide --update echo ":: Calling updatedb to update its database" updatedb fi
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-updateSi 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 *:
/etc/portage/profile/packagesMarcar nfs-utils como paquete del sistema (system)*net-fs/nfs-utils
Aplicando parches no normados
Usando epatch_user
La función
epatch_user se aplica en EAPIs menores o iguales que cinco, consultar la función eapply_user para EAPIs mayores o iguales que seis.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 eutils.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 "Gentoo Linux Manual de Gentoo: Trabajar con Portage" overrides earlier display title "Manual de Gentoo: Partes/Todo/Portage".