Manual Gentoo Linux x86: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. 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 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.confAlmacenar 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.
¡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:
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 x86.
/etc/portage/make.confUsing the stable branch# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="x86"
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: ~x86. 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
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 another, 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.
/etc/portage/make.confUsar la rama de pruebasACCEPT_KEYWORDS="~x86"
Por ejemplo, para seleccionar la rama de pruebas para una arquitectura x86, 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:
/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
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:
/etc/portage/package.unmaskDesenmascarando un paquete/version en particular=net-mail/hotwayd-0.8
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.6.21, añada la siguiente línea a package.mask:
/etc/portage/package.maskEnmascarar gentoo-sources con una versión posterior a 6.6.21>sys-kernel/gentoo-sources-6.6.21
dispatch-conf
dispatch-conf es una herramienta diseñada para combinar los archivos ._cfg0000_<nombre>. Los archivos ._cfg0000_<nombre> son generados por Portage cuando intenta sobreescribir un archivo en un directorio protegido por la variable CONFIG_PROTECT.
Empleando dispatch-conf, se puede actualizar la configuración mientras se registran todos los cambios realizados. dispatch-conf guarda las diferencias entre las distintas configuraciones como parches o utilizando el sistema de control de versiones RCS. Esto implica que, si se comete un error en la actualización de un archivo de configuración, se puede regresar a la versión anterior del archivo en cualquier momento.
Cuando se utiliza dispatch-conf, se le puede indicar que deje el archivo de configuración tal cual, que utilice la nueva configuración, que permita editar la configuración actual o que combine los cambios interactivamente. dispatch-conf además dispone de algunas funcionalidades adicionales:
- Automáticamente actualizar el fichero de configuración si las actualizaciones solamente afectan a comentarios.
- Automáticamente actualizar los ficheros de configuración que sólo difieren en la cantidad de espacios en blanco.
Hay que asegurarse de primero editar /etc/dispatch-conf.conf y crear el directorio al que hace referencia la variable archive-dir. Después, ejecutar dispatch-conf:
root #dispatch-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.
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:
/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
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/localrepoA 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_nameThen define the EAPI used for the profiles within the repository:
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
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
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 localrepoAdding 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-developmentroot #emerge --syncSoftware 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.6.21 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-6.6.21 como instalado manualmentesys-kernel/gentoo-sources-6.6.21
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/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/bashrcEnganchando las fases postinst y postrmif [ "${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-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
Patching source code using user patches in /etc/portage/patches/
User patches provide a way to apply patches to package source code when sources are extracted before installation. This can be useful for applying upstream patches to unresolved bugs, or simply for local customizations.
Patches need to be dropped into /etc/portage/patches/. They will automatically be applied during package installation.
Patches can be dropped into any of the following directories:
- /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: 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 x86:Trabajar con Portage" overrides earlier display title "Manual:X86/Todo/Portage".