Manual Gentoo Linux : Trabajar con Gentoo

Bienvenido a Portage

Portage es probablemente la más importante innovación de Gentoo en la gestión de software. Debido a su potente flexibilidad y una gran cantidad de funcionalidades, es frecuentemente apreciado como la mejor herramienta de gestión de software disponible para Linux.

Portage esta completamente escrito en Python y Bash y, por tanto, totalmente a la vista de los usuarios al ser ambos lenguajes interpretados.

La mayoría de usuarios trabajarán con Portage a través de la herramienta emerge. Este capítulo no pretende duplicar la información disponible en la página de man sobre emerge. Para una completa información sobre las opciones de emerge, por favor, consulte la página del manual:

usuario $man emerge

El repositorio Gentoo

Ebuilds

Cuando hablamos sobre paquetes, nos referimos normalmente a programas software disponibles para los usuarios de Gentoo a través del repositorio Gentoo. Este repositorio es una colección de ebuilds, archivos que contienen toda la información que Portage necesita para mantener el software (instalar, buscar, etc.). Estos ebuilds residen por defecto en .

Cuando se pida a Portage que ejecute alguna acción relacionada con los programas, éste utilizará los ebuilds de su sistema como base. Por tanto, es importante que actualice los ebuilds de su sistema para que Portage conozca el nuevo software, actualizaciones de seguridad, etc.

Actualizar el repositorio Gentoo

El repositorio Gentoo se actualiza normalmente con rsync, una utilidad rápida de transferencia de archivos incremental. La actualización es muy sencilla, ya que la orden emerge proporciona una interfaz para rsync:

root #emerge --sync

En ocasiones, hay aplicadas restricciones de cortafuegos que impiden que rsync conecte con los servidores espejo. En estos casos, el repositorio Gentoo puede ser actualizado vía las instantáneas del mismo generadas diariamente. La herramienta emerge-webrsync recupera e instala en su sistema la instantánea mas reciente.

root #emerge-webrsync

Mantenimiento del software

Buscar software

Para buscar software utilizando el repositorio Gentoo, puede emplear las funcionalidades de búsquedas propias de emerge. Por defecto, emerge --search devuelve el nombre de los paquetes cuyo nombre coincide (tanto total como parcialmente) con el término de búsqueda introducido.

Por ejemplo, para buscar todos los paquetes que tengan "pdf" en su nombre:

user $emerge --search pdf

Si quiere buscar también en las descripciones puede utilizar la opción --searchdesc (o -S).

user $emerge --searchdesc pdf

Cuando eche un vistazo al resultado, notará que le proporciona mucha información. Los campos son etiquetados claramente con lo cual no entraremos en explicar sus significados.

CODE Ejemplo de salida de una búsqueda

*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Instalar software

Una vez que haya encontrado el nombre del software que necesite, puede fácilmente instalarlo con emerge: simplemente añada el nombre del paquete. Por ejemplo, para instalar gnumeric:

root #emerge --ask app-office/gnumeric

Muchas aplicaciones dependen unas de otras, esto implica que cualquier intento de instalar un cierto paquete de software podría derivar en la instalación de varias dependencias. No se preocupe. Portage maneja también las dependencias. Si quiere conocer qué instalará Portage cuando le pida que instale un cierto paquete, añada la opción --pretend. Por ejemplo:

root #emerge --pretend gnumeric

Para hacer lo mismo, pero elegir de forma interactiva si desea continuar o no con la instalación, agregue el indicador --ask:

root #emerge --ask gnumeric

Cuando le pida a Portage que instale un paquete, descargará las fuentes necesarias desde Internet (si fuera necesario) y las guardará por defecto en /var/cache/distfiles/. Después, el paquete será descomprimido, compilado e instalado. Si quiere que Portage solamente descargue las fuentes sin instalarlas, añada la opción --fetchonly a la orden emerge:

root #emerge --fetchonly gnumeric

Encontrar la documentación de un paquete instalado

Muchos paquetes vienen con su propia documentación. Algunas veces, el ajuste USE doc determina si la documentación debe instalarse o no. Puede comprobar la existencia del ajuste USE doc con la orden emerge -vp categoría/paquete:

root #emerge -vp media-libs/alsa-lib

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild   R    ] media-libs/alsa-lib-1.1.3::gentoo  USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB

La mejor manera de activar el ajuste USE doc es por paquete, por medio de /etc/portage/package.use, de manera que solo obtendrá la documentación para los paquetes que le interesan. Activando este ajuste de manera global puede causar problemas con dependencias circulares. Para más información lea la sección acerca de ajustes USE.

Una vez que el paquete está instalado, su documentación se encuentra normalmente en un subdirectorio llamado igual que el paquete dentro del directorio /usr/share/doc.

user $ls -l /usr/share/doc/alsa-lib-1.1.3

total 16
-rw-r--r-- 1 root root 3098 Mar  9 15:36 asoundrc.txt.bz2
-rw-r--r-- 1 root root  672 Mar  9 15:36 ChangeLog.bz2
-rw-r--r-- 1 root root 1083 Mar  9 15:36 NOTES.bz2
-rw-r--r-- 1 root root  220 Mar  9 15:36 TODO.bz2

Una forma más segura de listar los ficheros de documentación instalados es utilizar la opción --filter de equery. equery se utiliza para consultar la base de datos de portage y se incluye como parte del paquete app-portage/gentoolkit:

user $equery files --filter=doc alsa-lib

 * Searching for alsa-lib in media-libs ...
 * Contents of media-libs/alsa-lib-1.1.3:
/usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2
/usr/share/doc/alsa-lib-1.1.3/NOTES.bz2
/usr/share/doc/alsa-lib-1.1.3/TODO.bz2
/usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2

La opción --filter se puede utilizar con otras reglas para ver las localizaciones de instalación para muchos otros tipos de ficheros. La funcionalidad añadida se puede revisar en la página del manual de equery: man 1 equery.

Desinstar software

Para eliminar software de un sistema de forma segura, utilizar emerge --deselect. Esto le indicará a Portage que un paquete ya no es necesario y que está disponible para su limpieza a través de --depclean.

root #emerge --deselect gnumeric

Cuando un paquete ya no es seleccionado, el paquete y sus dependencias que se instalaron automáticamente cuando se instaló el software, permanecerán. Para hacer que Portage localice todas las dependencias que puede ser eliminadas actualmente, utilice la funcionalidad de emerge --depclean. Hablaremos de esto un poco más adelante.

Actualizar el sistema

Para mantener el sistema en perfecto estado (incluidas las últimas actualizaciones de seguridad) es necesario actualizar el sistema regularmente. Como Portage sólo comprueba los ebuilds en el repositorio Gentoo, lo primero que hay que hacer es actualizar este repositorio usando emerge --sync. Después se puede actualizar el sistema usando emerge --deep --update @world.

Con --deep, Portage buscará las versiones más nuevas de las aplicaciones que están instaladas (bien explicitamente, bien como dependencias). Sin --deep, solo verificará las versiones de las aplicaciones que están instaladas explícitamente (las aplicaciones enumeradas en /var/lib/portage/world); no verificará sus dependencias. Por lo tanto, esta opción casi siempre debería usarse:

root #emerge --update --deep @world

El comando de actualización estándar debe incluir --changed-use o --newuse debido a posibles cambios dentro de los perfiles del repositorio, o si se han modificado las configuraciones USE del sistema. Portage verificará entonces si el cambio requiere la instalación de nuevos paquetes o la recompilación de los existentes:

root #emerge --update --deep --newuse @world

Meta-paquetes

Algunos paquetes del repositorio Gentoo no tienen contenido real pero son utilizados para instalar un conjunto de paquetes. Por ejemplo, el paquete kde-plasma/plasma-meta instalará el entorno de escritorio KDE Plasma en su sistema incluyendo varios paquetes relacionados con Plasma y también sus dependencias.

Para eliminar dicho paquete del sistema, ejecutar emerge --deselect en el paquete no tendrá mucho efecto ya que las dependencias del paquete permanecen en el sistema.

Portage tiene la funcionalidad de eliminar las dependencias huérfanas, pero la disponibilidad de software necesita que primero actualice completamente su sistema, incluyendo los nuevos cambios que ha aplicado si actualizó los ajustes USE. Después de esto, puede ejecutar emerge --depclean para eliminar las dependencias huérfanas. Cuando haya terminado, podría ser necesario reconstruir las aplicaciones que estuvieran enlazadas dinámicamente a las que acaban de ser eliminadas, a pesar de que recientemente se ha añadido a Portage soporte para este asunto.

Todo esto se lleva a cabo a través de dos órdenes:

root #emerge --update --deep --newuse @world

root #emerge --ask --depclean

Licencias

A partir de la versión 2.1.7 de Portage, puede aceptar o rechazar la instalación de software basada en esta licencia. Todos los paquetes del árbol contienen una entrada LICENSE en sus ebuilds. Ejecutando emerge --search categoría/paquete le mostrará la licencia del paquete.

Important
A modo de exención de responsabilidad y limitación de responsabilidad, la variable LICENSE en un ebuild es meramente una guía para los desarrolladores y usuarios de Gentoo. No es una declaración legal ni una garantía de que reflejará la licencia de cada archivo instalado por un ebuild. No se debe confiar en ella para obtener una representación legal completamente precisa de todos los archivos proporcionados por un paquete. Para obtener garantías, los administradores de sistemas deben realizar una comprobación exhaustiva de cada archivo instalado por un paquete para comprobar el alineamiento y/o el cumplimiento de la licencia. Si se encuentra una inconsistencia en el ebuild, informe del error para sugerir un cambio en los valores asignados a la variable LICENSE del ebuild.

Por defecto, Portage permite licencias que son aprobadas explícitamente por la Fundación del Software Libre, la Iniciativa para el Código Abierto, o que siguen la Definición de Software Libre.

La variable que controla las licencias permitidas es ACCEPT_LICENSE, la cual se puede ajustar en el archivo /etc/portage/make.conf. En el siguiente ejemplo, se muestra este valor por defecto:

FILE /etc/portage/make.confEl ajuste ACCEPT_LICENSE por defecto

ACCEPT_LICENSE="-* @FREE"

Con esta configuración, los paquetes con una licencia de software libre o de documentación se podrán instalar. No se podrá instalar software que no sea libre.

Es posible ajustar ACCEPT_LICENSE globalmente en /etc/portage/make.conf, o puede especificarlo de forma que afecte a solo un paquete en el fichero /etc/portage/package.license.

Por ejemplo, si quiere permitir la licencia google-chrome para usar el paquete www-client/google-chrome, añada lo siguiente a /etc/portage/package.license:

FILE /etc/portage/package.licenseAceptar la licencia google-chrome para el paquete google-chrome

www-client/google-chrome google-chrome

Esto permite la instalación del paquete www-client/google-chrome pero impide la instalación del paquete www-plugins/chrome-binary-plugins aunque tengan la misma licencencia.

O para permitir el normalmente necesario sys-kernel/linux-firmware:

FILE /etc/portage/package.licenseAceptar las licencias para el paquete linux-firmware

# Aceptación de la licencia para linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable

# Aceptación de cualquier licencia que permita la redistribución
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

Important
Las licencias se almacenan en el directorio /licenses/, y los grupos de licencias se guardan en el archivo /profiles/license_groups. La primera entrada de cada línea en letras MAYÚSCULAS, es el nombre del grupo de licencias, y cada entrada detrás de ésta es una licencia individual.

Los grupos de licencias definidos en la variable ACCEPT_LICENSE se prefijan con un símbolo @. Un ajuste posible (que era el anterior que usaba Portage por defecto) es permitir todas la licencias excepto End User License Agreements (EULAs) (Acuerdo de licencia de usuario final o CLUF) que requiere leer y firmar un acuerdo de aceptación. Para conseguir esto, se deben aceptar todas las licencias (usando *) y entonces eliminar las licencias en el grupo EULA tal y como se indica a continuación.

FILE /etc/portage/make.confAceptar todas las licencias excepto EULAs

ACCEPT_LICENSE="* -@EULA"

Observe que este ajuste también acepta software y documentación no libres.

Cuando Portage se queja

Terminología

Como mencionamos anteriormente, Portage es muy potente y soporta muchas características de las que carecen otras herramientas de gestión de software. Para comprender esto, explicaremos unos cuantos aspectos de Portage sin profundizar demasiado en los detalles.

Con Portage, diferentes versiones de un mismo paquete pueden coexistir en un sistema. Mientras otras distribuciones tienden a renombrar el paquete con sus versiones (por ejemplo gtk+2 and gtk+3). Portage usa una tecnología llamada SLOTs (ranuras). Un ebuild declara un cierto SLOT para su versión. Ebuilds con diferentes SLOTs pueden coexistir en el mismo sistema. Por ejemplo, el paquete gtk+ tiene ebuilds con SLOT="2" y SLOT="3".

También existen paquetes que proporcionan la misma funcionalidad pero están implementados de maneras distintas. Por ejemplo, metalogd, sysklogd, y syslog-ng son todos paquetes de registro del sistema. Aplicaciones que necesitan la disponibilidad de un "registrador del sistema" no pueden depender, por ejemplo, de metalogd, ya que el resto de registradores del sistema son igualmente válidos. Portage permite virtuals: cada paquete de registro del sistema se lista como una dependencia "exclusiva" del servicio de registro en el paquete virtual/logger de la categoría virtual, de esta forma las aplicaciones pueden depender del paquete virtual/logger. Cuando se instala el paquete, se obtendrá el primer paquete de registro mencionado, a menos que ya se haya instalado previamente un paquete que ofrezca el servicio (en este caso, la dependencia virtual ya está satisfecha).

Los programas del repositorio Gentoo puede residir en diferentes ramas. Por defecto, su sistema solamente acepta paquetes que Gentoo considera estables. La mayoría de los paquetes nuevos, cuando son aceptados, ingresan en la rama inestable. Esto implica que necesitan hacerse más pruebas antes de marcarlo como estable. Aunque los ebuilds de estos programas está en el repositorio Gentoo, Portage no los actualizará hasta que sean marcados como estables.

Algunos programas solo están disponibles para unas pocas arquitecturas. O los programas no funcionan en otras arquitecturas, o necesitan más pruebas, o el desarrollador que añade el programa al repositorio Gentoo no es capaz de verificar si el paquete funciona en diferentes arquitecturas.

Cada instalación de Gentoo adhiere un cierto perfil el cual contiene, entre otra información, la lista de paquetes necesarios para que el sistema funcione normalmente.

Paquetes bloqueados

CODE Advertencia de Portage sobre paquetes bloqueados

[ebuild  N     ] x11-wm/i3-4.20.1  USE="-doc -test"
[blocks B      ] x11-wm/i3 ("x11-wm/i3" is soft blocking x11-wm/i3-gaps-4.20.1)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
    x11-wm/i3

  (x11-wm/i3-gaps-4.20.1-1:0/0::gentoo, installed) pulled in by
    x11-wm/i3-gaps required by @selected

Los ebuilds contienen campos específicos que informan a Portage sobre sus dependencias. Hay dos posibles dependencias: dependencias de compilación, declaradas en la variable DEPEND y dependencias en tiempo de ejecución, declaradas en RDEPEND. Cuando una de estas dependencias marca explícitamente un paquete o paquete virtual como no compatible, se produce un bloqueo.

Aunque las versiones recientes de Portage son lo suficientemente inteligentes para resolver los bloqueos de menor importancia sin necesidad de la intervención del usuario, ocasionalmente necesitará resolverlo a mano como se explica abajo.

Para corregir un bloqueo, los usuarios pueden optar por no instalar el paquete o desinstalar el paquete conflictivo para empezar y poder seguir. En el ejemplo dado, se puede optar por no instalar x11-wm/i3 o eliminar primero x11-wm/i3-gaps. Normalmente es mejor simplemente indicarle a Portage que ya no se desea el paquete, con emerge --deselect x11-wm/i3-gaps, por ejemplo, para eliminarlo del archivo de world en lugar de eliminar el paquete en sí de manera forzada.

También puede ocurrir que vea los paquetes en conflicto con operadores lógicos concretos, como por ejemplo <media-video/mplayer-1.0_rc1-r2. En este caso, actualizar a la versión más reciente del paquete bloqueante debería eliminar el bloqueo.

También es posible que dos paquetes que aún no se han instalado se estén bloqueando mutuamente. En este caso (poco frecuente), se debería investigar por que necesitamos instalar ambos. En la mayoría de los casos se puede realizar con uno solo de los paquetes. Si no, por favor envíe un informe de error al sistema de seguimiento de errores de Gentoo.

Paquetes enmascarados (masked)

CODE Aviso de Portage sobre paquetes enmascarados

!!! all ebuilds that could satisfy "bootsplash" have been masked.

CODE Aviso de Portage sobre paquetes enmascarados - razon

!!! possible candidates are:
  
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

Cuando quiera instalar un paquete que no está disponible para su sistema, recibirá un error de enmascaramiento. Debería probar a instalar una aplicación distinta que este disponible para su sistema o esperar hasta que el paquete este disponible. Siempre hay una razón para que un paquete esté enmascarado:

Causa del enmascaramiento	Descripción
~arch keyword	La aplicación no está suficientemente probada para estar en la rama estable. Espere unos días o semanas y pruebe de nuevo.
-arch keyword or -* keyword	La aplicación no funciona en la arquitectura de destino. Si no es así, informe del error.
Sin keyword	La aplicación aún no se ha probado en la arquitectura de destino. Pida al equipo de adaptación de la arquitectura que pruebe el paquete o que pruebelo por ellos e informe de los resultados en el sitio web Bugzilla de Gentoo. Consulte /etc/portage/package.accept_keywords y Accepting a keyword for a single package.
package.mask	El paquete se ha mostrado corrupto, inestable o aún peor y ha sido expresamente marcado como "no-usar".
profile	El paquete no es adecuado para su perfil (profile) actual. La aplicación, si es instalada, puede romper el sistema o simplemente no es compatible con el perfil en uso.
license	La licencia del paquete no es compatible con los valores de ACCEPT_LICENSE. Permitir su licencia o el grupo de licencias adecuado indicándolo en /etc/portage/make.conf o en /etc/portage/package.license

Cambios necesarios en los ajustes USE

CODE Aviso de Portage sobre necesidad de cambiar un ajuste USE

The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

También puede que se muestre el siguiente mensaje de error, si no se ha habilitado --autounmask:

CODE Error de Portage por ser necesario cambiar un ajuste USE

emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Esta advertencia y error suceden cuando se quiere instalar un paquete que no solo depende de otro paquete, sino que requiere que ese paquete se haya construido con un ajuste USE en particular (o un conjunto de ajustes USE). En el ejemplo dado, el paquete app-text/feelings necesita construirse con USE="test", sin embargo, este ajuste USE no está habilitado en el sistema.

Para resolver esta situación, puede añadir el ajuste USE requerido a sus ajustes globales en /etc/portage/make.conf, o definirlo específicamente para el paquete en /etc/portage/package.use.

Dependencias perdidas

CODE Aviso de Portage sobre falta de dependencias

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
  
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.

La aplicación que está tratando instalar depende de otro paquete que no esta disponible para su sistema. Por favor, compruebe Bugzilla para ver si el problema se conoce o no, en este caso informe de ello. A menos que este mezclando ramas esto no debería ocurrir y lo consideraremos un error.

Nombre ambiguo del ebuild

CODE Aviso de Portage sobre nombres de ebuilds ambiguos

[ Results for search key : listen ]
[ Applications found : 2 ]
  
*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD
  
*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2
  
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

La aplicación que quiere instalar tiene un nombre que corresponde con más de un paquete. Necesita aportar también el nombre de la categoría. Portage le informará de los posibles casos entre los que puede elegir.

Dependencias circulares

CODE Aviso de Portage sobre dependencias circulares

!!! Error: circular dependencies: 
  
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

Dos (o más) paquetes que quiere instalar dependen uno de otro y, por tanto, no pueden instalarse. Esto casi siempre se considera un error en el repositorio Gentoo. Por favor, vuelva a sincronizar después de un tiempo e inténtelo de nuevo. También puede comprobar Bugzilla para saber si se tiene conocimiento sobre el tema o si no, en cuyo caso informe sobre ello.

Fallo en la descarga

CODE Aviso de Portage sobre error en la descarga

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

Portage no es capaz de descargar las fuentes para una aplicación específica y tratará de continuar instalando el resto de aplicaciones (si es posible). Este fallo puede deberse a que un servidor réplica no esta bien sincronizado o a que el ebuild apunta a una localización incorrecta. El servidor donde residen las fuentes podría estar caído por alguna razón.

Pruebe después de una hora y vea si el problema persiste.

Protección del perfil del sistema

CODE Aviso de Portage sobre paquete protegido por el perfil

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

Está intentando eliminar un paquete que es parte fundamental de su sistema. Éste se haya en su perfil y es necesario, por tanto, no debería ser eliminado del sistema.

Errores en la verificación de la integridad (digest)

CODE Error de verificación de integridad

>>> checking ebuild checksums
!!! Digest verification failed:

Esto es un síntoma de que algo no ha ido bien en el repositorio de Gentoo, a menudo causado por un error cometido cuando es envía un ebuild al repositorio de Gentoo.

Cuando falla la verificación de la integridad (digest), no intente recalcularla. El ejecutar ebuild algo manifest no va a resolver el problema, posiblemente lo podría empeorar.

En lugar de esto, espere una o dos hora que el repositorio se estabilice. Es probable que el error haya sido detectado enseguida, pero podrá tomar algún tiempo para que propague la corrección a los servidores rsync réplica. Mientras espera, revise Bugzilla a ver si alguien ya ha reportado el problema o pregunte en #gentoo (webchat) (IRC). Si no, siga adelante y cree una incidencia para el ebuild roto.

Una vez que compruebe que se ha reparado el error, tal vez quiera volver a sincronizar el repositorio de ebuilds de Gentoo para obtener la suma de control reparada.

Important
Procure no sincronizar el repositorio de ebuilds de Gentoo más de una vez al día. Tal y como se indica en las directrices de netiqueta de Gentoo (también se muestra cuando se lanza emerge --sync), los usuarios que sincronicen sus repositorios muy a menudo serán bloqueados temporalmente para evitar que los sincronicen durante un tiempo. Los usuarios que abusen continuamente ignorando esta directriz podrían ser bloqueados indefinidamente. A menos que sea absolutamente necesario, en la mayoría de los casos es mejorar esperar 24 horas para sincronizar de nuevo de modo que las resincronizaciones no carguen los servidores réplica de Gentoo.

¿Qué son los ajustes USE?

La idea que hay detrás de los ajustes USE

Al instalar Gentoo, los usuarios toman decisiones según el entorno con el que están trabajando. Una configuración para un servidor difiere de una configuración para una estación de trabajo. Una estación de trabajo de juegos difiere de una estación de trabajo de renderizado 3D.

Estas diferencias no solo dependen de los paquetes instalados, si no también de las características para las que ciertos paquetes tienen soporte. Si no necesita OpenGL, ¿para qué molestarse en instalar OpenGL y construir la mayoría de sus aplicaciones con soporte OpenGL? Si no quiere usar KDE, ¿para qué molestarte en compilar paquetes con soporte para KDE si podrían funcionar perfectamente sin él?

Para ayudar a los usuarios a decidir qué instalar/activar o no, necesitamos que el usuario especifique su entorno de una manera sencilla. Esto obliga al usuario a decidir que es lo que realmente quiere; además de facilitar a Portage, nuestro sistema de gestión de paquetes, la tarea de tomar decisiones útiles.

Definición de ajuste USE

Poner los ajustes USE. Una ajuste de este tipo es una palabra clave que incorpora información de soporte y dependencia para un determinado concepto. Si un determinado ajuste USE está habilitado, Portage sabrá que el administrador del sistema desea soporte para la palabra clave elegida. Por supuesto, esto puede alterar la información de dependencia de un paquete. Según el ajuste USE, ésto puede requerir la incorporación de "muchas" más dependencias para cumplir con los cambios de dependencia solicitados.

Eche un vistazo a un ejemplo concreto: el ajuste USE kde. Si este ajuste no está establecido en la variable USE (o si el valor tiene un prefijo con un signo menos: -kde), entonces todos los paquetes que tienen soporte opcional para KDE serán compilado sin soporte KDE. Todos los paquetes que tengan una dependencia opcional de KDE se instalarán "sin" instalar las bibliotecas de KDE (como dependencia).

Cuando el ajuste kde está habilitado, esos paquetes se compilarán "con" soporte para KDE, y las bibliotecas de KDE "si" se instalarán como dependencia.

Al definir correctamente los ajustes USE, el sistema se adaptará específicamente a las necesidades del administrador del sistema.

Uso de los ajustes USE

Declarar ajustes USE permanentes

Todos los ajustes USE se declaran dentro de la variable USE. Para simplificar al usuario la tarea de buscar y escoger ajustes USE, ya proporcionamos una configuración predeterminada. Esta configuración es un compendio de ajustes que creemos se utilizan frecuentemente por los usuarios de Gentoo. Dicha configuración predeterminada se declara en los ficheros make.defaults que forman parte de su perfil.

El perfil al que atiende su sistema lo indica el enlace simbólico /etc/portage/make.profile. Cada perfil funciona sobre otro, más extenso, y el resultado final es una suma de todos ellos. El perfil más alto es el perfil base (/profiles/base)..

Para ver los ajustes USE activados (permanentemente), use emerge --info:

root #emerge --info | grep ^USE

USE="a52 aac acpi alsa branding cairo cdr dbus dts ..."

Esta variable contiene bastantes palabras clave. No modifique el fichero make.defaults para ajustar la variable USE a sus necesidades: ¡Los cambios en estos ficheros se perderán al actualizar el repositorio de Gentoo!

Para modificar esta configuración predeterminada, necesita añadir o eliminar palabras clave a la variable USE. Para llevarlo a cabo, se define la variable USE en /etc/portage/make.conf. En esta variable añada los ajustes USE que necesite o elimine los que no quiera. Para eliminarlos coloque el símbolo menos (-) delante.

Por ejemplo, para eliminar el soporte para KDE y Qt además de añadir soporte para LDAP, puede definirse el siguiente ajuste USE en /etc/portage/make.conf:

FILE /etc/portage/make.confActualizar USE en make.conf

USE="-kde -qt5 ldap"

Declarar ajustes USE para paquetes específicos

En algunas ocasiones, los usuarios quieren declarar un determinado ajuste USE para una (o un par) de aplicaciones pero no de forma general para todo el sistema. Para conseguir esto, edite /etc/portage/package.use. Normalmente package.use es sólo un archivo, sin embargo también puede ser un directorio lleno de archivos subordinados; lea el consejo de abajo y man 5 portage para obtener más información acerca de cómo usar esta convención. Los siguientes ejemplos asumen que package.use es sólo un archivo.

Por ejemplo, para disponer únicamente de soporte para Blu-ray en el paquete VLC media player:

FILE /etc/portage/package.useHabilitar soporte de Blu-ray para VLC

media-video/vlc bluray

Tip
Si package.use ya existe como un directorio (a diferencia de un único fichero), los paquetes pueden modificar sus ajustes USE simplemente creando ficheros dentro del directorio package.use/. Cualquier convención acerca del nombrado de ficheros debería funcionar, sin embargo es prudente implementar un esquema de nombrado coherente. Una convención es simplemente utilizar el nombre del paquete como título del fichero hijo. Por ejemplo, se puede definir el ajuste USE bluray para el paquete media-video/vlc de la forma siguiente:

root #echo "media-video/vlc bluray" >> /etc/portage/package.use/vlc

Por supuesto también puede desactivar el empleo específico de un ajuste USE para una aplicación en concreto. Por ejemplo si no quiere soporte para bzip2 en PHP (pero lo quiere para otros paquetes al declarar ese ajuste USE en make.conf):

FILE /etc/portage/package.useDeshabilitar soporte bzip2 para PHP

dev-lang/php -bzip2

Declarar ajustes USE temporales

A veces necesitará utilizar una cierta configuración de USE tan solo una vez. En lugar de editar /etc/portage/make.conf dos veces (una para hacer y otra para deshacer los cambios) puede declarar la variable USE como una variable de entorno. Recuerde que, si utiliza este método, cuando vuelva a emerger o actualice este aplicación (tanto si es particular como si forma parte de una actualización del sistema) ¡Perderá los cambios!

En el siguiente ejemplo se elimina temporalmente el valor pulseaudio de la variable USE durante la instalación de SeaMonkey:

root #USE="-pulseaudio" emerge www-client/seamonkey

Precedencia

Por supuesto, hay una determinada precedencia respecto a qué configuración tiene prioridad sobre la configuración del USE. La precedencia para la configuración del USE es (el primero tiene la mínima prioridad):

1. Configuración predeterminada de USE declarada en los archivos make.defaults de su perfil.
2. Configuración definida por el usuario en /etc/portage/make.conf
3. Configuración definida por el usuario en /etc/portage/package.use
4. Configuración definida por el usuario como variable de entorno

Para ver el valor final de USE tal y como lo verá Portage, ejecute emerge --info. Se listarán una serie de variables importantes (incluyendo la variable USE) con sus valores actuales tal como los conoce Portage.

root #emerge --info

Adaptar todo el sistema a nuevos ajustes USE

Si ha cambiado sus ajustes USE y desea actualizar todo su sistema para que utilice el nuevo ajuste, utilice la opción de emerge llamada --newuse:

root #emerge --update --deep --newuse @world

A continuación, ejecute una limpieza completa de Portage para eliminar las dependencias que habían sido instaladas en su "antiguo" sistema pero que han quedado obsoletas por los nuevos ajustes USE.

Important
Compruebe la lista proporcionada de paquetes "obsoletos" para asegurarse de que no elimine paquetes necesarios. En el siguiente ejemplo, añadir el indicador --pretend (-p) hace que depclean solo enumere los paquetes sin eliminarlos:

root #emerge --pretend --depclean

Cunado depclean haya terminado, emerge puede que solicite reconstruir las aplicaciones que se han enlazado dinámicamente a objetos compartidos ofrecidos por paquetes que probablemente se hayan desinstalad. Portage conservará las bibliotecas necesarias hasta que esta acción se realice para evitar romper las aplicaciones. Portage almacena lo que necesita ser reconstruido en el conjunto preserved-rebuild. Para reconstruir los paquetes necesarios, se puede lanzar:

root #emerge @preserved-rebuild

Cuando todo esto haya terminado, su sistema estará utilizando la nueva configuración de los ajustes USE.

Ajustes USE específicos de un paquete

Ver los ajustes USE disponibles

Veamos el ejemplo de seamonkey: ¿Qué ajustes USE influyen sobre él? Para averiguarlo, usamos emerge con las opciones --pretend (simula llevar a cabo la acción) y --verbose (obtener una salida más detallada):

root #emerge --pretend --verbose www-client/seamonkey

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild  N     ] www-client/seamonkey-2.48_beta1::gentoo  USE="calendar chatzilla crypt dbus gmp-autoupdate ipc jemalloc pulseaudio roaming skia startup-notification -custom-cflags -custom-optimization -debug -gtk3 -jack -minimal (-neon) (-selinux) (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite {-test} -wifi" L10N="-ca -cs -de -en-GB -es-AR -es-ES -fi -fr -gl -hu -it -ja -lt -nb -nl -pl -pt-PT -ru -sk -sv -tr -uk -zh-CN -zh-TW" 216,860 KiB
 
Total: 1 package (1 new), Size of downloads: 216,860 KiB

emerge no es la única herramienta disponible para esta labor. De hecho, tenemos una herramienta llamada equery dedicada a obtener información sobre los paquetes; la cual se encuentra en el paquete app-portage/gentoolkit. En primer lugar, instale gentoolkit:

root #emerge --ask app-portage/gentoolkit

Ahora ejecute equery con el argumento uses para ver los indicadores USE de un determinado paquete. Por ejemplo, para el paquete app-portage/portage-utils:

user $equery --nocolor uses =app-portage/portage-utils-0.93.3

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-portage/portage-utils-0.93.3:
 U I
 + + nls       : Add Native Language Support (using gettext - GNU locale utilities)
 + + openmp    : Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE="openmp"
 + + qmanifest : Build qmanifest applet, this adds additional dependencies for GPG, OpenSSL and BLAKE2B hashing
 + + qtegrity  : Build qtegrity applet, this adds additional dependencies for OpenSSL
 - - static    : !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically

Satisfacer condiciones REQUIRED_USE

Algunos ebuilds obligan o prohíben ciertas combinaciones en los ajustes USE para funcionar correctamente. Estas se expresan mediante un conjunto de condiciones que forman una expresión dentro de REQUIRED_USE. Estas condiciones aseguran que, todas las funciones y dependencias están completas y que la construcción tenga éxito y que todo funcione como se espera. Si alguna condición no se cumple, emerge le avisará y le pedirá que corrija el problema.

Ejemplo	Descripción
REQUIRED_USE="foo? ( bar )"	Si se activa foo, se debe activar bar
REQUIRED_USE="foo? ( !bar )"	Si se activa foo, no se debe activar bar
REQUIRED_USE="foo? ( || ( bar baz ) )"	Si se activa foo, se debe activar bar o baz
REQUIRED_USE="^^ ( foo bar baz )"	Se debe activar exactamente uno de los ajustes foo bar o baz
REQUIRED_USE="|| ( foo bar baz )"	Se debe activar al menos uno de los ajustes foo bar o baz
REQUIRED_USE="?? ( foo bar baz )"	Se puede activar no mas de uno de los ajustes foo bar o baz

Características de Portage

Portage tiene varias características adicionales que hacen de su experiencia con Gentoo algo mucho mejor. Muchas de estas características residen en ciertas herramientas software que mejoran el rendimiento, la estabilidad, la seguridad, ...

Para activar o desactivar ciertas características de Portage necesita editar la variable FEATURES del archivo /etc/portage/make.conf. Esta variable contiene una lista con las palabras clave de cada característica separadas por un espacio en blanco. En algunos casos necesita además instalar la herramienta que implementa la característica.

No todas las características que soporta Portage están aquí reflejadas. Para una consulta completa por favor revise la página de la ayuda referente a make.conf

user $man make.conf

Para conocer qué características están siendo utilizadas por defecto, ejecute emerge --info y busque la variable FEATURES o utilice grep:

user $emerge --info | grep ^FEATURES=

Compilación Distribuida

Usar distcc

distcc es un programa para distribuir un trabajo de compilación a través de muchas, no necesariamente idénticas, máquinas en una red. Los clientes de distcc envían toda la información necesaria a los servidores DistCC disponibles (corriendo distccd) así pueden compilar trozos de código fuente para el cliente. El resultado final, es un tiempo de compilación más rápido.

Puede encontrar información más detallada sobre distcc (e información de como tenerlo funcionando sobre Gentoo) en el artículo sobre Distcc/es.

Instalar distcc

Distcc se distribuye con un monitor gráfico para monitorizar las tareas que su computador está enviando para compilar. Esta herramienta es instalada automáticamente si activa USE="gtk".

root #emerge --ask sys-devel/distcc

Activar el soporte para distcc en Portage

Añada distcc a la variable FEATURES dentro de /etc/portage/make.conf. Hecho esto, edite la variable MAKEOPTS e incremente a la cantidad de trabajos de compilación en paralelo que su sistema permite. Una pauta conocida para configurarla es poner -jN donde N es el número de CPUs que ejecutan distccd (incluyendo la máquina local) más uno, pero quizá obtenga mejores resultados con otros números.

Ahora ejecute distcc-config y cree una lista de los servidores distcc disponibles. Para un ejemplo simple, supondremos que los servidores DistCC son 192.168.1.102 (el host local), 192.168.1.103 y 192.168.1.104 (los dos hosts "remotos"):

root #distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Por supuesto, no se olvide ejecutar también el demonio distccd:

root #rc-update add distccd default

root #/etc/init.d/distccd start

Almacenamiento en caché de fragmentos ya compilados

Acerca de ccache

ccache es un caché de compilación rápida. Cuando compila un programa, puede guardar resultados intermedios, de forma que, si recompila el mismo programa y versión, el tiempo de compilación se reducirá ampliamente. La primera vez que se ejecuta ccache, ésta será más lenta que una compilación normal. Recompilaciones posteriores deberían ser más rápidas. La herramienta ccache solo es útil si va a recompilar la misma versión de la aplicación muchas veces; por lo tanto en la mayoría de los casos es útil únicamente para los desarrolladores de software.

Para mas información sobre ccache, visite su página principal.

Warning
ccache puede causar numerosos fallos de compilación. Algunas veces ccache mantendrá objetos con código obsoleto o ficheros corruptos que pueden llevar a que no se pueda hacer emerge de ciertos paquetes. Si esto ocurre (Si obtiene errores como "File not recognized: File truncated"), intente recompilar la aplicación con ccache deshabilitado (FEATURES="-ccache" en /etc/portage/make.conf o de un golpe desde la linea de comandos con lo que sigue) antes de informar del error:

root #FEATURES="-ccache" emerge --oneshot <category/package>

Instalar ccache

Para instalar ccache, ejecute la siguiente orden:

root #emerge --ask dev-util/ccache

Activar el soporte ccache en Portage

Primero, edite el fichero /etc/portage/make.conf y añada ccache a los valores definidos en la variable FEATURES. Si no existe FEATURES, entonces deberá crearla. A continuación, añada una nueva variable llamada CCACHE_SIZE y dele el valor 2G:

FILE /etc/portage/make.confHabilitar el soporte de ccache en Portage

FEATURES="ccache"
CCACHE_SIZE="2G"

Para comprobar si ccache funciona, pídale a ccache que te muestre las estadísticas. Ya que Portage utiliza un directorio diferente para guardar los datos, se necesita fijar la variable CCACHE_DIR para reflejar ésto:

root #CCACHE_DIR="/var/tmp/ccache" ccache -s

La ruta /var/tmp/ccache/ es el directorio por defecto que emplea Portage para ccache; si quiere cambiar esta variable, configure CCACHE_DIR en /etc/portage/make.conf.

Sin embargo, si ejecuta simplemente ccache, empleará como directorio por defecto ${HOME}/.ccache/, que es la razón por la cual necesita configurar la variable CCACHE_DIR cuando se le pide a Portage que muestre las estadísticas de ccache.

Usar ccache fuera de Portage

Si quiere utilizar ccache para compilaciones que no tengan que ver con Portage, añada /usr/lib/ccache/bin/ al principio de su variable PATH (antes de /usr/bin). Esto puede llevarse a cabo editando el fichero ~/.bash_profile de su directorio home de usuario. ~/.bash_profile es una de las maneras de definir variables PATH.

FILE ~/.bash_profilePoner la ruta de ccache delante de cualquier otra

PATH="/usr/lib/bin:${PATH}"

Soporte para paquetes binarios

Crear paquetes precompilados

Portage permite la instalación de paquetes precompilados.

Para crear un paquete precompilado puede utilizar la orden quickpkg si el paquete está instalado en su sistema, o hacer emerge con las opciones --buildpkg o --buildpkgonly.

Si quiere que Portage cree paquetes precompilados de cada paquete individual que instale, añada buildpkg a la variable FEATURES.

Se puede obtener mayor soporte para crear conjuntos de paquetes precompilados usando Catalyst. Para más información sobre Catalyst, lea las preguntas frecuentes sobre Catalyst.

Instalar paquetes precompilados

A pesar de que Gentoo no proporciona uno, puede crear un repositorio central donde almacene paquetes precompilados. Si quiere utilizar este repositorio, necesita que Portage lo conozca a través de la variable PORTAGE_BINHOST que debe apuntar al repositorio. Por ejemplo, si los paquetes precompilados están en ftp://buildhost/gentoo:

FILE /etc/portage/make.confAñadir la localización de PORTAGE_BINHOST

PORTAGE_BINHOST="ftp://buildhost/gentoo"

Cuando quiera instalar un paquete precompilado, añada la opción --getbinpkg a la orden emerge junto a la opción --usepkg. La primera le indica a emerge que descargue el paquete precompilado del servidor definido previamente, mientras que el segundo indica a emerge que intente instalar el paquete precompilado antes de buscar el código fuente y compilarlo.

Por ejemplo, para instalar gnumeric a través de paquetes precompilados:

root #emerge --usepkg --getbinpkg gnumeric

Más información sobre las opciones para utilizar paquetes precompilados con emerge puede consultarse en la página man de ayuda:

user $man emerge

Distribuir paquetes precompilados a otros

Si distribuye paquetes precompilados a otros, asegúrese que eso está permitido. Compruebe los términos para la distribución del desarrollador del paquete. Por ejemplo, para un paquete publicado bajo GNU GPL, las fuentes deben estar disponibles junto con los binarios.

Los ebuilds pueden definir una restricción bindist en su variable RESTRICT si los binarios construidos no son distribuibles. En algunos casos esta restricción está condicionada a uno o mas ajustes USE.

Por defecto, Portage no enmascara ningún paquete debido a esta restricción. Esto puede cambiarse globalmente configurando la variable ACCEPT_RESTRICT en /etc/portage/make.conf. Por ejemplo, para enmascarar paquetes que tengan una restricción bindist añada la siguiente línea a make.conf:

FILE /etc/portage/make.confAceptar paquetes distribuibles en binario

ACCEPT_RESTRICT="* -bindist"

También es posible modificar el valor de la variable ACCEPT_RESTRICT añadiendo la opción --accept-restrict al comando emerge. Por ejemplo, --accept-restrict=-bindist temporalmente enmascarará paquetes con restricción bindist.

Considere también ajustar la variable ACCEPT_LICENSE cuando distribuya paquetes. Vea la sección de icencias para ello.

Important
Es exclusiva responsabilidad de cada usuario cumplir con los términos de licencia de los paquetes y con las leyes del pais de cada usuario. Las variables de metadatos definidas por los ebuilds (RESTRICT o LICENSE) pueden proporcionar indicaciones cuando la distribución de binarios no esté permitida, de manera que la obtención desde Portage o cuestiones respondidas por los desarrolladores de Gentoo no son declaraciones legales, y como tales, no debe confiarse en ellas. Sea cuidadoso de respetar las leyes de su ubicación física.

Descargar archivos

Verificar los archivos de distribución

Para verificar de nuevo la integridad y (potencialmente) descargar de nuevo los ficheros de distribución previamente eliminados o corruptos para todos los paquetes actualmente instalados, ejecutar:

root #emerge --ask --fetchonly --emptytree @world

Important
El contenido de esta página no se aplica a los usuarios que eligieron un perfil systemd en Elegir el perfil correcto.

Niveles de ejecución

Iniciando el sistema

Al iniciar, notará que pasará al frente suyo una gran cantidad de texto. Si pone atención, notará que estos textos son (normalmente) iguales cada vez que reinicie su sistema. La secuencia de todas estas acciones se llama la secuencia de inicio y es (más o menos) definido estáticamente.

En primer lugar, su gestor de arranque cargará en memoria la imagen del núcleo que definió en la configuración del gestor de arranque, después de lo cual, se indica a la CPU que debe ejecutar el núcleo. Al ser cargado y luego ejecutado inicializa todas las estructuras y tareas específicas del núcleo e inicia el proceso init.

Este proceso asegura que todos los sistemas de archivo (definidos en /etc/fstab) estén montados y listos para usar. Luego ejecuta varios guiones en /etc/init.d/, correspondientes a los servicios requeridos para tener un sistema correctamente iniciado.

Finalmente, al concluir la ejecución de los guiones, init activa los terminales (generalmente solo las consolas virtuales accesibles con Alt+F1, Alt+F2, etc.) fijándoles un proceso especial denominado agetty. Este proceso hará posible que pueda ingresar al sistema a través de uno de estos terminales ejecutando login.

Guiones de inicio

Ahora bien, init no solamente ejecuta los guiones contenidos en /etc/init.d/ de manera aleatoria. Aún más, no ejecuta todos los guiones del /etc/init.d/, solamente los que han sido seleccionados para ejecutar. Los guiones seleccionados para ejecutar se encuentran dentro del directorio /etc/runlevels/.

Primero, init ejecuta todos los guiones de /etc/init.d/ cuyos enlaces simbólicos se encuentran dentro de /etc/runlevels/boot/. Usualmente los iniciará en orden alfabético, pero algunos guiones tienen información relativa a dependencias, para lo cual otros guiones deben ser iniciados anteriormente.

Cuando se ejecuten todos los guiones referenciados en /etc/runlevels/boot/, init continua su trabajo con los guiones en /etc/runlevels/default/. Una vez más, usará el orden alfabético, salvo cuando hay dependencias, en cuyo caso es alterado el orden de inicio para realizar una secuencia válida de arranque. Esto último es también la razón por la que durante la instalación de Gentoo Linux se utiliza la opción default (por defecto), como en rc-update add sshd default.

¿Cómo funciona init?

Por supuesto que init no decide todo eso por su cuenta. Requiere un archivo de configuración que especifica las acciones a tomar. Este archivo es /etc/inittab.

Si recuerda la secuencia de inicio que se ha explicado, recordará que la primera acción de init es montar todos los sistemas de archivo. Esto está definido en la siguiente línea de /etc/inittab:

FILE /etc/inittabComando de inicialización

si::sysinit:/sbin/openrc sysinit

Esa línea dice a init que debe ejecutar /sbin/openrc sysinit al iniciar el sistema. El guión /sbin/openrc se encargan de la inicialización, con lo que podríamos decir que init no hace mucho, delega la tarea de inicialización del sistema a otro proceso.

En segundo lugar, init ejecutó los guiones con enlaces simbólicos en /etc/runlevels/boot/. Esto se define en la siguiente línea:

FILE /etc/inittabInvocación de la orden de arranque

rc::bootwait:/sbin/openrc boot

Una vez más, el guión OpenRC lleva a cabo las tareas necesarias. Note que la opción dada a OpenRC (boot) corresponde al subdirectorio en /etc/runlevels/ que será usado.

Ahora init revisa su archivo de configuración para ver que nivel de ejecución debe ejecutar. Para decidirlo, lee la siguiente línea de /etc/inittab:

FILE /etc/inittabSelección del nivel de ejecución por defecto

id:3:initdefault:

En este caso (para la mayoría de usuarios Gentoo), el identificador del nivel de ejecución será el 3. Con esta información init revisa qué debe ejecutar para iniciar el nivel de ejecución 3:

FILE /etc/inittabDefinición de los niveles de ejecución

l0:0:wait:/sbin/openrc shutdown
l1:S1:wait:/sbin/openrc single
l2:2:wait:/sbin/openrc nonetwork
l3:3:wait:/sbin/openrc default
l4:4:wait:/sbin/openrc default
l5:5:wait:/sbin/openrc default
l6:6:wait:/sbin/openrc reboot

La línea que define el nivel 3, de nuevo usa el guión openrc para iniciar los servicios (ahora con el parámetro por defecto default). Note una vez más que el parámetro pasado al guión openrc corresponde al subdirectorio de /etc/runlevels/.

Al terminar OnpenRC, init decide qué consolas virtuales debe activar y qué órdenes se deben ejecutar para cada una:

FILE /etc/inittabDefinición de terminales

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Niveles de ejecución existentes

Ha visto que init utiliza un esquema de numeración para decidir cual nivel de ejecución debe activar. Un nivel de ejecución es un estado en el cual su sistema está corriendo y contiene guiones (del nivel de ejecución o initscripts) que serán ejecutados al ingresar o salir del nivel de ejecución.

En Gentoo, hay siete niveles de ejecución definidos: tres internos y cuatro definidos por el usuario. Los internos se llaman sysinit, shutdown y reboot y hacen exactamente lo que implican sus nombres: inicialización, apagado y reinicio del sistema.

Los niveles de ejecución definidos por el usuario están acompañados de un subdirectorio bajo /etc/runlevels/: boot, default, nonetwork y single. El nivel de ejecución boot inicia los servicios necesarios que requieren los demás niveles de ejecución. Los tres niveles de ejecución restantes difieren respecto a los servicios que inician: default es para uso diario, nonetwork en caso de no requerirse la red y single es utilizado en caso de necesitar arreglar el sistema.

Trabajando con los guiones de inicio

Los guiones iniciados por el proceso openrc son llamados guiones de inicio o init scripts. Cada guión en /etc/init.d/ puede ser ejecutado con los parámetros start, stop, restart, zap, status, ineed, iuse, iwant, needsme, usesme o wantsme.

Para iniciar, parar o reiniciar un servicio (y sus respectivas dependencias), deben usarse start, stop y restart:

root #rc-service postfix start

Note
Solo los servicios que necesiten del servicio nombrado serán parados o reiniciados. Los demás servicios, (aquellos que usen el servicio nombrado, pero que no lo necesiten) continuarán sin ser tocados.

Si desea parar un servicio, pero no los que dependan de el, puede usar la opción --nodeps junto con el parámetro stop:

root #rc-service --nodeps postfix stop

Si desea ver el estado de un servicio (iniciado, parado, ...) puede usar el parámetro status:

root #rc-service postfix status

Si la respuesta a status indica que el servicio está corriendo, pero realmente no es así, puede reajustarlo manualmente con el parámetro zap:

root #rc-service postfix zap

Para preguntar por las dependencias que tiene un servicio, puede usar iwant, iuse o ineed. Con ineed puede ver qué servicios son realmente necesarios para el correcto funcionamiento del servicio nombrado. Por otra parte, iwant o iuse muestran los servicios que pueden ser usados por el servicio nombrado, pero que no son requeridos para su correcto funcionamiento.

root #rc-service postfix ineed

De igual manera, puede indagar que servicios requieren el servicio nombrado (needsme) o cuáles pueden usarlo (usesme o wantsme):

root #rc-service postfix needsme

Modificar los niveles de ejecución

rc-update

El sistema de inicio de Gentoo usa un árbol de dependencias para decidir qué servicios deben iniciarse primero. Como ésta es una tarea tediosa, que no deseamos que nuestros usuarios tengan que hacer manualmente, hemos creado unas herramientas para facilitar la administración de los niveles de ejecución y los guiones de inicio.

Con rc-update puede añadir o quitar guiones de inicio a un nivel de ejecución. La herramienta rc-update automáticamente usará el guión depscan.sh para reconstruir el árbol de dependencias.

Añadir y quitar servicios

En instrucciones anteriores ya hemos agregado guiones de inicio al nivel de ejecución "por defecto" (default). Lo que quiere decir "por defecto" (default) se ha explicado antes en este documento. Junto al nivel de ejecucuión, el guión rc-update requiere un segundo parámetro que define la acción a llevar a cabo: add, del o show para agregar, borrar o mostrar.

Para añadir o quitar un guión de inicio, use rc-update con el parámetro add o del, seguido por el nombre del guión de inicio y el nivel de ejecución, por ejemplo:

root #rc-update del postfix default

La orden rc-update -v show mostrará todos los guiones de inicio con los niveles de ejecución donde ejecutarán:

root #rc-update -v show

Es posible ejecutar también rc-update show (sin -v) simplemente para ver los guiones de inicio activos y sus respectivos niveles de ejecución.

Configurar los servicios

¿Por qué se necesita configuración adicional?

Los guiones de inicio pueden ser bastante complejos, por lo cual no es interesante que los usuarios modifiquen directamente el guión de inicio, ya que esto puede ser propenso a errores. Sin embargo es importante poder configurar estos servicios, en caso que se quieren dar más opciones al servicio.

Una segunda razón para mantener esta información fuera del guión de inicio es para poder actualizar estos guiones sin que los cambios de configuración sean perdidos.

El directorio conf.d

Gentoo provee una manera fácil de configurar estos servicios: cada guión de inicio configurable tiene un archivo dispuesto en /etc/conf.d/. Por ejemplo, el guión de inicio apache2 (llamado /etc/init.d/apache2) tiene un archivo de configuración de nombre /etc/conf.d/apache2, el cual contiene las opciones a pasar al servidor web Apache 2 en el momento de inicio:

FILE /etc/conf.d/apache2Ejemplo de opciones para el guión de inicio apache2

APACHE2_OPTS="-D PHP5"

Este tipo de archivo de configuración contiene solamente variables (como en /etc/portage/make.conf), lo que facilita la configuración de servicios. También nos permite suministrar información adicional acerca de las variables (en forma de comentarios).

Crear guiones de inicio

Otro recurso útil es la guía de guiones de servicios de OpenRC.

¿Es necesario?

No, escribir un guión de inicio normalmente no hace falta, ya que Gentoo ofrece guiones listos para usar para todos los servicios suministrados. Sin embargo, puede haber instalado un servicio sin usar Portage, en cuyo caso probablemente tenga que crear un guión de inicio.

No utilice el guión de inicio proporcionado por el servicio si no está escrito explícitamente para Gentoo: ¡los scripts de inicio de Gentoo no son compatibles con los scripts de inicio utilizados por otras distribuciones! Es decir, a menos que la otra distribución esté utilizando OpenRC.

Esquema

El esquema básico de un guión de inicio se muestra a continuación.

CODE Ejemplo de esquema de guión de inicio (tradicional)

#!/sbin/openrc-run

depend() {
# (Información acerca de las dependencias)
}

start() {
# (Órdenes requeridas para iniciar el servicio)
}

stop() {
# (Órdenes requeridas para parar el servicio)
}

CODE Esquema ejemplo de guión de inicio (actualizado)

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="Demonio FooBar"
 
description="FooBar es un demonio que bebe"
extra_started_commands="drink"
description_drink="Abre su boca y traga reflexivamente"
 
depend() {
#  (Información de dependencias)
}
 
start_pre() {
#  (Comandos necesarios para prepararse para iniciar el servicio)
    # Asegurarse de que nuestros directorios son correctos
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commandos necesarios para limpiar después del servicio)
    # Limpiar todas las salpicaduras
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Empezando a beber"
    ${command} --drink beer
    eend $? "No he podido beberme ninguna cerveza :("
}

Cualquier guión de inicio requiere la definición de la función start() o de la variable command. El resto de secciones son opcionales.

Dependencias

Existen tres ajustes relacionados con las dependencias que puede definir y que influyen en el arranque o secuenciación de los guiones de inicio: want, use y need. Aparte de estas dos, existen también dos métodos, llamados before y after, que influyen en el orden . Estos últimos no son dependencias en sí mismos, no provocan el fallo del guión de inicio si el guión seleccionado no está programado para ser iniciado (o falla al iniciar).

• Los ajustes use informan al sistema de inicio que este guión utiliza funcionalidad ofrecida por el guión seleccionado, sin embargo no depende directamente de él. Un buen ejemplo sería use logger o use dns. Si estos servicios están disponibles, se usarán de forma correcta, pero aunque no tenga instalado un programa de registro (logger) o servidor DNS, los servicios funcionarán de todos modos. Si estos servicios están presentes en su sistema, entonces se arrancarán antes del guión que los utiliza.
• El ajuste want es similar a use con una excepción. use considera únicamente los servicios que se añadieron a un nivel de inicio. want intentará iniciar cualquier servicio disponible incluso si no se ha añadido a un nivel de inicio.
• El ajuste need es una dependencia inevitable. Esto significa que el guión que necesita otro guión, no podrá arrancar antes de que el otro guión se arranque de forma correcta. Si el otro guión es reiniciado, entonces el guión que depende de él será reiniciado igualmente.
• Cuando se utiliza before, el guión dado es arrancado antes del guión seleccionado si el seleccionado forma parte del nivel de inicio. Por lo tanto, si el guión de inicio xdm define before alsasound, será arrancado antes que el guión alsasound, pero solo si alsasound está también programado para ser arrancado en el mismo nivel de inicio. Si alsasound no está programado para arrancar, entonces este ajuste en particular no tiene efecto y el guión xdm será arrancado cuando el sistema de inicio lo juzgue apropiado.
• De modo similar, after informa al sistema de inicio que el guión dado debería ser arrancado antes que el seleccionado si el guión seleccionado forma parte de nivel de inicio. En caso contrario, el ajuste no tiene efecto y el guión será arrancado por el sistema de inicio cuando éste lo juzgue apropiado.

Debería quedar claro una vez leido lo anterior, que need es el único ajuste que define un "auténtica" dependencia ya que afecta al hecho de que el guión sea arrancado o no. Las demás son simplemente apuntes al sistema de inicio para clarificar el orden en el que los guiones deben (o deberían ser arrancados).

Si echa un vistazo al muchos de los guiones de inicio disponibles en Gentoo, observará que algunos tienen dependencias de objetos que no son guiones de inicio. Estos "objetos" son los llamados virtuals (virtuales).

Una dependencia virtual es una dependencia suministrada por un servicio, pero no únicamente por un servicio en concreto. Su guión de inicio puede depender de un gestor de registro de sistema, habiendo disponibilidad de varios (metalogd, syslog-ng, sysklogd, ...). Como no se necesitan todos (ningún sistema normal tiene todos estos gestores de registro instalados y corriendo) nos aseguramos que todos estos servicios provean una dependencia virtual.

A modo de ejemplo examinemos la información de dependencia del servicio postfix:

FILE /etc/init.d/postfixInformación de dependencias del servicio poxfix

depend() {
 need net
 use logger dns
 provide mta
}

Como podemos ver, el servicio postfix:

• requiere la dependencia (virtual) net (suministrada, por ejemplo por, /etc/init.d/net.eth0)
• usa la dependencia (virtual) logger (suministrada, por ejemplo por, /etc/init.d/syslog-ng)
• usa la dependencia (virtual) dns (suministrada por ejemplo por, /etc/init.d/named)
• provee la dependencia (virtual) mta (común a todos los servidores de correo electrónico)

Controlar la ordenación

Tal y como se ha descrito en la sección anterior, puede indicarle al sistema de inicio qué orden debe seguir para arrancar (o parar) los guiones. Este orden es manejado tanto por los ajustes de dependencia use y need, como por los ajustes de orden before y after. Como ya hemos descrito estos ajustes, echemos un vistazo al servicio portmap como ejemplo de guión de inicio.

FILE /etc/init.d/portmapInformación de dependencias del servicio portmap

depend() {
 need net
 before inetd
 before xinetd
}

También puede usar el carácter que engloba "*" para referirse a todos los servicios, aunque no es aconsejable.

CODE Usando el caracter englobador *

depend() {
 before *
}

Si el servicio debe escribir en discos locales, necesitará localmount. Si coloca algo en /var/run/, como un archivo PID, entonces debe iniciarse después de bootmisc:

CODE Declaración de dependencia que necesita localmount y ejecutarse después de bootmisc

depend() {
 need localmount
 after bootmisc
}

Funciones estándar

Junto con la función depend(), hará falta definir la función start(), que contiene las órdenes necesarias para inicializar su servicio. Es aconsejable usar las funciones ebegin y eend para informarle al usuario acerca de lo que está ocurriendo:

CODE Ejemplo de función start()

start() {
 if [ "${RC_CMD}" = "restart" ];
 then
  # Hacer algo en caso de que restart requiera algo más que parar y arrancar
 fi

 ebegin "Arrancando mi_servicio"
 start-stop-daemon --start --exec /path/to/mi_servicio \
  --pidfile /path/to/my_pidfile
 eend $?
}

Ambos --exec y --pidfile deben usarse en las funciones start y stop. Si el servicio no crea un archivo pid, entonces use --make-pidfile si es posible, aunque debe probar esto para estar seguro. De otra manera, no use archivos pid. Puede también agregar --quiet a las opciones al start-stop-daemon, pero esto no es recomendado a no ser que el el servicio sea extremadamente verboso. Usando --quiet puede interferir con la depuración si el servicio no logra arrancar.

Otro ajuste notable usado en el ejemplo anterior es la comprobación del contenido de la variable RC_CMD. Al contrario que el sistema de guiones de inicio anterior, el nuevo sistema OpenRC no soporta funcionalidad de reinicio específica de los guiones. En lugar de esto, el guión necesita comprobar el contenido de la variable RC_CMD para var si una función (sea start() o stop()) se llama como parte del reinicio o no.

Note
Asegúrese que --exec efectivamente llame a un servicio y no solamente a un guión que lanza un servicio y termina -- después de todo, eso es lo que se espera que haga un guión de inicio.

Si requiere más ejemplos de funciones start(), favor leer directamente las fuentes de los guiones de inicio en su directorio /etc/init.d/.

Otra función que puede definir es stop(). Sin embargo, ¡No está obligado a definir esta función! Nuestro sistema de inicio es lo suficientemente inteligente para rellenar esta función por sí mismo si utiliza start-stop-daemon.

CODE Ejemplo de función stop()

stop() {
 ebegin "Parando mi_servicio"
 start-stop-daemon --stop --exec /path/to/mi_servicio \
  --pidfile /path/to/my_pidfile
 eend $?
}

Si el servicio ejecuta otro guión (por ejemplo, Bash, Python o Perl), y este guión cambia posteriormente de nombre (por ejemplo, foo.py a foo), entonces hará falta agregar --name al start-stop-daemon. Debe especificar el nombre al cual cambiará el guión. En este ejemplo, un servicio inicia foo.py, el cual cambia de nombre a foo:

CODE Ejemplo de definición de un servicio que lanza el guión foo

start() {
 ebegin "Arrancando mi_guion"
 start-stop-daemon --start --exec /path/to/mi_guion \
  --pidfile /path/to/my_pidfile --name foo
 eend $?
}

El start-stop-daemon tiene una excelente página man si requiere más información:

user $man start-stop-daemon

La sintaxis de los guiones de inicio de Gentoo está basada en el intérprete de comandos POSIX, de manera que es libre de usar construcciones compatibles con sh dentro del guión de inicio. No utilice otras construcciones, por ejemplo las del tipo bash, en los guiones de inicio para asegurarse de que los guiones funcionen en el futuro incluso si se cambia el sistema de inicio de Gentoo.

Añadir opciones personalizadas

Si desea que su guión de inicio soporte un mayor número de opciones de las que hemos encontrado hasta ahora, debe agregar la opción a una de las siguientes variables y crear una función con el mismo nombre que la opción. Por ejemplo, para dar soporte a una opción llamada restartdelay:

• extra_commands - El comando está disponible con el servicio en cualquier estado
• extra_started_commands - El comando está disponible cuando se arranca el servicio
• extra_stopped_commands - El comando está disponible cuando se para el servicio

CODE Ejemplo de definición de la opción restartdelay

extra_started_commands="restartdelay"

restartdelay() {
 stop
 sleep 3 # Esperar 3 segundos antes de iniciarse de nuevo
 start
}

Important
¡La función restart() no puede ser sobreescrita en OpenRC!

Variables para la configuración de servicios

No hay que hacer nada para dar soporte a un archivo de configuración en /etc/conf.d/: si su guión de inicio se ejecuta, los siguientes archivos serán automáticamente leídos -sourced- (es decir, las variables estarán disponibles para ser usadas):

• /etc/conf.d/YOUR_INIT_SCRIPT
• /etc/conf.d/basic
• /etc/rc.conf

También, si su guión de inicio provee una dependencia virtual (como net), el archivo asociado a esa dependencia (el /etc/conf.d/net) será leído también.

Cambiar el comportamiento del nivel de ejecución

¿Quién se podría beneficiar?

Muchos usuarios de equipos portátiles conocen la situación: en casa necesita iniciar net.eth0 mientras que puede no querer iniciar net.eth0 mientras está de viaje (cuando no hay una red disponible). Con Gentoo puede modificar el comportamiento del nivel de ejecución para sus propios propósitos.

Por ejemplo puede crear un segundo nivel de ejecución "default" con el cual puede arrancar y que utiliza otros guiones de inicio que le han sido asignados. Puede seleccionar al arrancar que nivel de ejecución quiere utilizar.

Utilizar softlevel

Antes de nada, cree el directorio para su segundo nivel de ejecución "default". Como ejemplo vamos a crear el nivel de ejecución offline:

root #mkdir /etc/runlevels/offline

Añada los guiones de inicio necesarios para el nuevo nivel de ejecución. Por ejemplo, si quiere una copia exacta de su actual "default" pero sin net.eth0:

root #cd /etc/runlevels/default

root #for service in *; do rc-update add $service offline; done

root #rc-update del net.eth0 offline

root #rc-update show offline

(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Incluso aunque se haya eliminado net.eth0 del nivel de ejecución offline, puede que udev quiera intentar iniciar cualquier dispositivo que detecte y lanzar los servicios apropiados, una funcionalidad llamada hotplugging (enchufado en caliente). Por defecto Gentoo no habilita esta funcionalidad.

Si quiere habilitar el hotplugging pero solo para un conjunto seleccionado de guiones, utilice la variable rc_hotplug en /etc/rc.conf:

FILE /etc/rc.confHabilitando hotplugging en la interfaz WLAN

rc_hotplug="net.wlan !net.*"

Note
Para más información sobre los servicios iniciados en función de dispositivos, consulte los comentarios del archivo /etc/rc.conf.

Ahora edite la configuración de su gestor de arranque y añada una nueva entrada para el nivel de ejecución offline. En dicha entrada, añada softlevel=offline como parámetero de arranque.

Utilizar bootlevel

Utilizar bootlevel es completamente análogo a softlevel. La única diferencia es que se define un segundo nivel de ejecución "boot" en lugar de un segundo "default".

Variables de entorno

Introducción

Una variable de entorno es un objeto designado para contener información usada por una o más aplicaciones. Usar variables de entorno hace que cualquiera pueda cambiar una opción de configuración para una o más aplicaciones fácilmente.

Ejemplos destacados

La siguiente tabla muestra un listado de variables de entorno usado por un sistema Linux y describe su uso. Valores de ejemplo se muestran después de la tabla.

Variable	Descripción
PATH	Esta variable contiene una lista de directorios separados por ":" en la cual el sistema buscará los archivos ejecutables. Al introducir el nombre de un ejecutable (como ls, rc-update o emerge) que no se encuentre en alguno de los directorios listados, el sistema no lo encontrará, (a menos que se introduzca la ruta completa, por ejemplo: /bin/ls).
ROOTPATH	Esta variable tiene la misma función que PATH, pero únicamente contiene los directorios que el sistema debe revisar cuando el usuario root introduce una orden.
LDPATH	Esta variable contiene una lista de directorios separados por ":" en la cual el enlazador dinámico busca para encontrar una librería.
MANPATH	Esta variable contiene una lista de directorios separados por ":" en los cuales la orden man buscará las páginas de manual.
INFODIR	Esta variable contiene una lista de directorios separados por ":" en la cual la orden info buscará las páginas info.
PAGER	Esta variable contiene la ruta hacia el programa utilizado para mostrar el contenido de los ficheros (como less o more).
EDITOR	Esta variable contiene la ruta hacia el programa utilizado para modificar el contenido de los archivos (como nano o vi).
KDEDIRS	Esta variable contiene una lista de directorios separados por ":" los cuales contienen material específico de KDE.
CONFIG_PROTECT	Esta variable una lista de directorios separados por espacio los cuales deben ser protegidos por Portage durante las actualizaciones de paquetes.
CONFIG_PROTECT_MASK	Esta variable una lista de directorios separados por espacio los cuales no deben ser protegidos por Portage durante las actualizaciones de paquetes.

A continuación puedes encontrar ejemplos de definiciones para todas estas variables:

CODE Ejemplos de asignaciones para las variables mencionadas

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less" EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
# Directorios que están protegidos durante las actualizaciones de paquetes.
# Observe el uso de \ (barras invertidas) al final de las siguientes líneas, que se interpretan como una sola línea delimitada por espacios.
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
# Directorios que _no_ están protegidos durante las actualizaciones de paquetes.
CONFIG_PROTECT_MASK="/etc/gconf"

Definir variables globales

El directorio env.d

Para centralizar las definiciones de estas variables, Gentoo introdujo el directorio /etc/env.d/. Dentro de este directorio se encuentran disponibles una serie de archivos, como 50baselayout, gcc/config-x86_64-pc-linux-gnu, etc. que contienen las variables que necesita la aplicación mencionada en su nombre.

Por ejemplo, cuando se instala gcc, el ebuild crea un archivo llamado gcc/config-x86_64-pc-linux-gnu que contiene las definiciones de las siguientes variables:

FILE /etc/env.d/gcc/config-x86_64-pc-linux-gnuVariables de entorno predeterminadas habilitadas para GCC 13

GCC_PATH="/usr/x86_64-pc-linux-gnu/gcc-bin/13"
LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/13:/usr/lib/gcc/x86_64-pc-linux-gnu/13/32"
MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man"
INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info"
STDCXX_INCDIR="g++-v13"
CTARGET="x86_64-pc-linux-gnu"
GCC_SPECS=""
MULTIOSDIRS="../lib64:../lib"

Otras distribuciones pueden indicarle al administrador del sistema que cambie o agregue dichas definiciones de variables de entorno en /etc/profile u otras ubicaciones. Gentoo, por otro lado, facilita a los administradores de sistemas (y a Portage) el mantenimiento y la gestión de las variables de entorno sin tener que tener en cuenta los numerosos archivos que pueden contener variables de entorno.

Por ejemplo, cuando se actualiza gcc, los archivos asociados en /etc/env.d/gcc también se actualizan sin solicitar ninguna interacción administrativa.

Existe la posibilidad ocasional de que se le solicite al administrador del sistema que configure una determinada variable de entorno para todo el sistema. Como ejemplo, tomemos la variable http_proxy. En lugar de editar un archivo en el directorio /etc/profile, cree un archivo llamado /etc/env.d/99local e ingrese la definición en él:

FILE /etc/env.d/99localAsignando una variable de entorno globalmente=bash

http_proxy="proxy.server.com:8080"

Al utilizar el mismo archivo para todas las variables de entorno personalizadas, los administradores del sistema tienen una descripción general rápida de las variables que ellos mismos han definido.

env-update

Varios archivos dentro del directorio /etc/env.d agregan definiciones a la variable PATH. Esto no es un error: cuando se ejecuta el comando env-update, agregará las distintas definiciones antes de actualizar de forma única cada variable de entorno, lo que facilita que los paquetes (o los administradores de sistemas) agreguen sus propias configuraciones de variables de entorno sin interferir con los valores ya existentes.

El guión env-update concatenará los valores alfabéticamente ordenados por el nombre de los ficheros de /etc/env.d/. Los nombres de fichero deben comenzar con dos dígitos decimales.

CODE Orden de actualización utilizada por env-update

09sandbox    50baselayout     51dconf
     +------------+----------------+-----------+
CONFIG_PROTECT_MASK="/etc/sandbox.d /etc/gentoo-release /etc/dconf ..."

La concatenación de variables no siempre funciona, solo con las siguientes variables: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH, and PYTHONPATH</va. Para el resto de variables, se utiliza el último valor definido (en orden alfabético de ficheros en /etc/env.d/).

Puede incluir más variables en esta lista de variables concatenadas añadiendo el nombre de la variable a la variable COLON_SEPARATED o a la variable SPACE_SEPARATED (definidas también en el fichero /etc/env.d/).

Cuando ejecute env-update, el guión creará todas las variables de entorno y las colocará en /etc/profile.env (el cual es usado por /etc/profile). Además, también extraerá la información de la variable LDPATH y la usará para crear /etc/ld.so.conf. Después de esto, ejecutará ldconfig para recrear el archivo usado por el enlazador dinámico: /etc/ld.so.cache.

Si quiere observar el efecto de env-update inmediatamente después de ejecutarlo, ejecute la siguiente orden para actualizar su entorno. Posiblemente, los usuarios que instalaron Gentoo ellos mismos, recordarán estas instrucciones de la instalación:

root #env-update && source /etc/profile

Note
La orden anterior actualiza únicamente las variables en la terminal actual, en las nuevas consolas y sus hijas. Sabiendo esto, si se está trabajando en X11, necesitará ejecutar source /etc/profile en las nuevas terminales que abra o reiniciar las X para que las nuevas terminales definan las nuevas variables. Si está utilizando un gestor de inicio, conviértase en root y reinicie el servicio /etc/init.d/xdm.

Important
No se pueden utilizar las variables del terminal para definir otras variables. Esto implica que cosas como TAL="$CUAL" (donde $CUAL es otra variable) están prohibidas.

Definir variables locales

Específicas de usuario

No siempre queremos definir variables de entorno globales. Por ejemplo, podríamos querer añadir /home/mi_usuario/bin y el directorio de trabajo actual (en el cual nos encontramos), a la variable PATH, pero no queremos que todos los usuarios de nuestro sistema lo tengan en su PATH. Si queremos definir una variable localmente, debemos usar ~/.bashrc o ~/.bash_profile:

FILE ~/.bashrcExtendiendo PATH para uso local

# Dos puntos sin incluir después un directorio son tratados como el directorio de trabajo actual
PATH="${PATH}:/home/mi_usuario/bin:"

Cuando vuelva a iniciar la sesión, su variable PATH será actualizada.

Específicas de la sesión

En ocasiones, se requieren definiciones aún más estrictas. Puede querer usar binarios de un directorio temporal que ha creado sin tener que usar la trayectoria completa a los binarios o sin editar ~/.bashrc. Para estos momentos necesitará esto.

En este caso, puede definir la variable PATH en su sesión activa usando la orden export. Mientras no cierre la sesión, la variable PATH usará los valores temporales.

root #export PATH="${PATH}:/home/my_user/tmp/usr/bin"