This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Gentoo Linux amd64 Manual de Gentoo: 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 emergeEl 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 /usr/portage.
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.
Actualizando 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 --syncEn ocasiones, hay aplicadas restricciones de cortafuegos que impiden que rsync conecte con los servidores espejo. En estos casos, actualice el repositorio Gentoo usando las instantáneas de Gentoo generadas diariamente. La herramienta emerge-webrsync recupera e instala en su sistema la instantánea mas reciente.
root #emerge-webrsyncUna ventaja adicional de utilizar emerge-webrsync es que permite al administrador descargar únicamente instantáneas del repositorio Gentoo que están firmadas con la clave GPG del equipo de ingeniería de versiones de Gentoo. Se puede encontrar más información sobre esto en la sección características de Portage en Obtener instantáneas validadas del repositorio Gentoo.
Mantenimiento de 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 pdfSi quiere buscar también en las descripciones puede utilizar la opción --searchdesc (o -S).
user $emerge --searchdesc pdfCuando 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.
* 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-2Instalar 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/gnumericMuchas 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 gnumericCuando le pida a Portage que instale un paquete, descargará las fuentes necesarias desde Internet (si fuera necesario) y las guardará por defecto en /usr/portage/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 gnumericEncontrar 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-libThese 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 los 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.3total 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.
Desinstalando software
Cuando quiera desinstalar un paquete software de su sistema, utilice emerge --unmerge. Esto le indicará a Portage que desinstale todos los archivos instalados por el paquete en su sistema excepto los archivos de configuración de esa aplicación si los había modificado después de la instalación. Esto le permite continuar trabajando con los mismos archivos de configuración si alguna vez decide volver a instalar la aplicación.
Portage no comprueba si el paquete que está intentando desinstalar es necesario para algún otro. A pesar de esto, le avisará cuando quiera eliminar un paquete importante que pueda romper su sistema si lo desinstala.
root #emerge --unmerge gnumericCuando desinstala un paquete de su sistema, las dependencias de ese paquete que se instalaron automáticamente cuando 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.
Actualizando su sistema
Para mantener su sistema en perfecto estado (sin mencionar la instalación de los últimas actualizaciones de seguridad) necesita actualizarlo frecuentemente. Partiendo de que Portage solamente comprueba los ebuilds en su repositorio Gentoo, lo primero sería actualizar el propio repositorio. Cuando tenga el repositorio Gentoo actualizado, puede actualizar su sistema con emerge --update @world. En el siguiente ejemplo, además hemos utilizado la opción --ask que le indica a Portage que muestre la lista de paquetes que quiere actualizar y pregunte si se quiere continuar:
root #emerge --update --ask @worldPortage buscará entonces las nuevas versiones de las aplicaciones que explícitamente haya instalado (las listadas en /var/lib/portage/world), sin embargo, no revisa minuciosamente sus dependencias. Si desea actualizar también esas dependencias, añada la opción --deep:
root #emerge --update --deep @worldAunque esto no indica todos los paquetes: algunos paquetes de su sistema son necesarios durante los procesos de compilación y construcción de los paquetes, pero, una vez que los paquetes se han instalado, estas dependencias ya no se necesitan. Portage denomina a éstas dependencias de construcción (build dependencies). Para incluirlas en un ciclo de actualización, añada --with-bdeps=y:
root #emerge --update --deep --with-bdeps=y @worldYa que las actualizaciones de seguridad también afectan a paquetes que no han sido explícitamente instalados en el sistema (pero que son dependencias de otros programas), es recomendable ejecutar la orden de arriba de vez en cuando.
Si ha cambiado últimamente alguno de sus ajustes USE quizá quiera añadir también --newuse. Portage comprobará si los cambios requieren la instalación de nuevos paquetes o la recompilación de los existentes:
root #emerge --update --deep --with-bdeps=y --newuse @worldMeta-paquetes
Algunos paquetes del repositorio Gentoo no tienen contenido real pero son utilizados para instalar un conjunto de paquetes. Por ejemplo, el paquete kde-apps/kde-meta instalará un entorno KDE completo en su sistema incluyendo varios paquetes relacionados con KDE y también sus dependencias.
Si quiere desinstalar dicho paquete de su sistema, ejecutando emerge --unmerge sobre el paquete no tendrá efecto total ya que las dependencias permanecerán en su 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 tres órdenes:
root #emerge --update --deep --newuse @world
root #emerge --depclean
root #revdep-rebuildrevdep-rebuild es parte del paquete app-portage/gentoolkit; no olvide instalarlo primero:
root #emerge --ask app-portage/gentoolkitLicencias
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.
Por defecto Portage permite todas las licencias, excepto Acuerdos de Licencia de Usuario Final (End User License Agreements o EULAs) que requieren la lectura y firma de un acuerdo de aceptación.
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:
/etc/portage/make.confValor por defecto de ACCEPT_LICENSEACCEPT_LICENSE="* -@EULA"
Con esta configuración, los paquetes que requieren interacción durante la instalación para aprobar su EULA no se podrán instalar. Los paquetes sin una EULA se podrán instalar.
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:
/etc/portage/package.licenseAceptar la licencia google-chrome para el paquete google-chromewww-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.
Las licencias se almacenan en el directorio /usr/portage/licenses/, y los grupos de licencias se guardan en el archivo /usr/portage/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 que se demanda frecuentemente es el de permitir únicamente la instalación de software y documentación libres. Para conseguir esto, se pueden eliminar todas las licencias aceptadas (mediante -*) y a continuación permitir solo las licencias en el grupo FREE, tal y como se muestra a continuación:
/etc/portage/make.confAceptar sólo software y documentación libreACCEPT_LICENSE="-* @FREE"
En este caso, "free" está definido por la FSF y OSI. Cualquier paquete cuya licencia no se ajuste a estos requisitos no se podrá instalar en su sistema.
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 freetype and freetype2). 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 freetype tiene ebuilds con SLOT="1" y SLOT="2".
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
[blocks B ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
!!! Error: the mail-mta/postfix package conflicts with another package. !!! both can't be installed on the same system together. !!! Please use 'emerge --pretend' to determine blockers.
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 igualmente en RDEPEND. Cuando una de estas dependencias marca explícitamente un paquete o paquete virtual como no compatible, se dispara 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 solucionar un bloqueo, puede elegir no instalar el paquete o desinstalar primero el paquete conflictivo. En el ejemplo anterior, puedes optar por no instalar postfix o eliminar primero ssmtp.
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)
!!! all ebuilds that could satisfy "bootsplash" have been masked.
!!! 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 o -* keyword | La aplicación no funciona en su arquitectura. Si Vd. cree que si funciona infórmelo en nuestro sitio web Bugzilla. |
| sin keyword | La aplicacion aún no ha sido probada en su arquitectura. Solicite al equipo que se ocupa de esa arquitectura que la pruebe o pruébela Vd. mismo e informe del resultado en nuestro sitio web Bugzilla. |
| 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
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:
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
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
[ 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
!!! 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
!!! 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
!!! 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)
>>> 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 (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.
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 cargan los servidores réplicad de Gentoo.
¿Qué son los ajustes USE?
Las ideas que hay detrás de los ajustes USE
Mientras esté instalando Gentoo (o cualquier otra distribución, incluso otro sistema operativo), tomará varias decisiones dependiendo del entorno en el que esté trabajando. Una instalación para un servidor es distinta a una para una estación de trabajo. También una estación de trabajo dedicada a juegos es diferente a una estación de trabajo que se use para renderizados en 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 un ajuste USE
Comencemos por definir qué son los ajustes USE. Un ajuste USE es una palabra clave que incorpora información de soporte y dependencias para un concepto en concreto. Si define un determinado ajuste USE, Portage sabrá que el usuario desea soporte para la palabra clave escogida. Por supuesto, también altera las dependencias de un paquete.
Veamos un ejemplo específico: la palabra clave kde. Si no la tiene en su variable USE, todos los paquetes que tengan soporte opcional para KDE se construirán sin él. Los que tengan una dependencia opcional con KDE se instalarán sin instalar las librerías de KDE (como dependencia). Si ha definido la palabra clave kde, entonces dichos paquetes sí se construirán con soporte para KDE, y las librería de KDE serán instaladas.
Definiendo correctamente las palabras clave, conseguirá un sistema confeccionado específicamente para sus necesidades.
¿Qué ajustes USE existen?
Hay dos tipos de ajustes USE: globales y locales.
- Un ajuste USE global lo usan varios paquetes, en todo el sistema. Es lo que la mayoría de la gente entiende como ajustes USE. Una lista de los ajustes USE globales se puede encontrar en el sitio principal o localmente en el archivo /usr/portage/profiles/use.desc.
- Un ajuste USE local lo utiliza un solo paquete para tomar decisiones específicas para dicho paquete. Una lista de los ajustes USE locales se puede encontrar en el sitio principal o localmente en el archivo /usr/portage/profiles/use.local.desc.
Usando los ajustes USE
Declarar ajustes USE permanentes
Como ya se ha dicho anteriormente, 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 (/usr/portage/profiles/base).
Para ver los ajustes USE activados (permanentemente), use emerge --info:
root #emerge --info | grep ^USEUSE="a52 aac acpi alsa branding cairo cdr dbus dts ..."
Como puede ver, 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:
/etc/portage/make.confActualizar USE en make.confUSE="-kde -qt4 -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:
/etc/portage/package.useHabilitar soporte de Blu-ray para VLCmedia-video/vlc bluray
Si package.use ya existe como un directorio (a diferencia de un único fichero), los paquetes pueden modificar de forma local 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 de forma local para el paquete media-video/vlc de la forma siguiente:root #echo "media-video/vlc bluray" >> /etc/portage/package.use/vlcPor 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):
/etc/portage/package.useDeshabilitar soporte bzip2 para PHPdev-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/seamonkeyPrecedencia
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):
- Configuración predeterminada de USE declarada en los archivos make.defaults de su perfil.
- Configuración definida por el usuario en /etc/portage/make.conf
- Configuración definida por el usuario en /etc/portage/package.use
- 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 --infoAdaptar su sistema completamente a los 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 @worldA 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.
Ejecutar emerge --depclean es una operación peligrosa y debería tratarse con cuidado. Revise en profundidad la lista de paquetes "obsoletos" y asegúrese de que no elimina ningún paquete que necesite. En el siguiente ejemplo hemos añadido
-p para mostrar la lista de paquetes que serían eliminados pero sin eliminarlos físicamente:
root #emerge -p --depcleanCuando haya finalizado la limpieza, ejecute revdep-rebuild para recompilar las aplicaciones que están enlazadas dinámicamente con los objetos que proporcionaban los paquetes eliminados. revdep-rebuild forma parte del paquete app-portage/gentoolkit; no olvide instalarlo antes con emerge.
root #revdep-rebuildCuando todo esto haya terminado, su sistema estará utilizando la nueva configuración de los ajustes USE.
Ajuste USE específicos de un paquete
Viendo 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/seamonkeyThese 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/gentoolkitAhora ejecute equery con el argumento uses para ver los ajustes USE de un paquete en concreto. Por ejemplo, en el caso del paquete gnumeric:
user $equery --nocolor uses =gnumeric-1.12.31[ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for app-office/gnumeric-1.12.31: U I + + introspection : Add support for GObject based introspection - - libgda : Enable database support through gnome-extra/libgda. - - perl : Enable perl plugin loader. + + python : Enable python plugin loader. + + python_targets_python2_7 : Build with Python 2.7
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.
A continuación se muestran algunos ejemplos de estas expresiones REQUIRED_USE:
| 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.confPara 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.
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=gnome o USE=gtk.
root #emerge --ask sys-devel/distccActivar el soporte 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 startCompilación utilizando caché
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, 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 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.
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) antes de informar del error.Instalar ccache
Para instalar ccache, ejecute la siguiente orden:
root #emerge --ask dev-util/ccacheActivar 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:
/etc/portage/make.confHabilitar el soporte de ccache en PortageFEATURES="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 -sLa 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.
Utilizar ccache para compilaciones de C sin relación con 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.
~/.bash_profilePoner la ruta de ccache delante de cualquier otraPATH="/usr/lib/bin:${PATH}"
Soporte para Paquetes Binarios
Crear paquetes binarios
Portage soporta la instalación de paquetes precompilados. A pesar de que Gentoo no proporciona paquetes precompilados por sí mismo, Portage puede funcionar perfectamente con 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.
Puede encontrar mayor soporte para la creación de conjuntos de paquetes precompilados con catalyst. Para más información sobre catalyst, por favor lea las Preguntas frecuentes sobre Catalyst (en inglés).
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:
/etc/portage/make.confAñadir la localización de PORTAGE_BINHOSTPORTAGE_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 gnumericMás información sobre las opciones para utilizar paquetes precompilados con emerge puede consultarse en la página man de ayuda:
user $man emergeDistribuir 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:
/etc/portage/make.confAceptar paquetes distribuibles en binarioACCEPT_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 Licencias para ello.
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 los Ficheros
Userfetch
Cuando Portage se ejecuta por el usuario root, FEATURES="userfetch" permitirá que Portage ejecute sin los privilegios de superusuario mientras obtiene las fuentes. Este es una pequeña mejora en la seguridad.
If userfetch is set in FEATURES be sure to change the owner of all the files beneath /usr/portage using the chown command with root privileges:
root #chown --recursive --verbose portage:portage /usr/portageObtener instantáneas validadas del repositorio Gentoo
Administrators can opt to update the local Gentoo ebuild repository with a cryptographically validated snapshot as released by the Gentoo infrastructure. This ensures that no rogue rsync mirror is adding unwanted code or packages to the repositories the system will be downloading.
Lo siguiente es un método actualizado para poner en marcha y utilizar la forma de sincronizar con emerge-webrsync usando repos.conf.
Las claves OpenPGP de los medios publicados por Gentoo están ahora disponibles como un llavero de claves binario. Estas se puede instalar a través del paquete app-crypt/gentoo-keys.
root #emerge --ask app-crypt/gentoo-keysEsto instalará el llavero en la localización /var/lib/gentoo/gkeys/keyrings/gentoo/release.
/etc/portage/make.confHabilitar soporte GPG en PortageFEATURES="webrsync-gpg" PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release"
/etc/portage/repos.conf/gentoo.confLimpiar la variable sync-uri[DEFAULT] main-repo = gentoo [gentoo] # Deshabilitar la sincronización limpiando los valores o asignando auto-sync = no # ¡No definir los valores de las variables en este fichero de configuración utilizando comillas ('' o "")! # Para portage-2.2.18 utilice 'websync' # Para portage-2.2.19 y superior utilice 'webrsync' (websync se renombró a webrsync) sync-type = webrsync sync-uri = auto-sync = yes
Asegúrese de que ha instalado app-crypt/gnupg:
root #emerge --ask app-crypt/gnupgUtilice gpg para verificar que las claves del llavero son las correctas:
root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --with-fingerprint --list-keysVerifique las huellas digitales de la(s) clave(s) comparándolas con las listadas en la página oficial de proyecto de ingenieria de lanzamientos de Gentoo.
If any of the keys installed from app-crypt/gentoo-keys should expire, run gkeys from app-crypt/gkeys to refresh them from the key server:
root #emerge --ask app-crypt/gkeysroot #gkeys refresh-key -C gentooRepita la siguiente orden para cada clave que quiera verificar. (Sustituya el idendificador de clave '0x...' por la clave que quiera verificar.)
root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --edit-key 0xDB6B8C1F96D8BF6D trustDebe aparecer un menu GPG en línea de comandos, verifique la clave completa y finalice el programa tecleando lo siguiente:
gpg>4
gpg>quit
El sistema está ahora preparado para sincronizar utilizando únicamente instantáneas verificadas mediante OpenPGP/gpg.
Algunas opciones de las órdenes están disponibles para realizar la sincronización.
Únicamente una de las siguientes órdenes es necesaria para sincronizar. Le el Only one of the following commands is needed to sync. Lea el See the artículo wiki de la sincronización de Portage para más información.
root #emerge --syncroot #emaint sync -aroot #emaint sync --repo gentooroot #emerge-webrsyncVerify distfiles
To re-verify the integrity and (potentially) re-download previously removed/corrupted distfiles for all currently installed packages, run:
root #emerge --ask --fetchonly --emptytree @world
Niveles de ejecución
Iniciando su 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 (init scripts)
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:
/etc/inittabInitialization commandsi::sysinit:/sbin/openrc sysinit
This line tells init that it must run /sbin/openrc sysinit to initialize the system. The /sbin/openrc script takes care of the initialization, so one might say that init doesn't do much - it delegates the task of initializing the system to another process.
En segundo lugar, init ejecutó los guiones con enlaces simbólicos en /etc/runlevels/boot/. Esto se define en la siguiente línea:
/etc/inittabBoot command invocationrc::bootwait:/sbin/openrc boot
Again the openrc script performs the necessary tasks. Note that the option given to openrc (boot) is the same as the subdirectory of /etc/runlevels/ that is used.
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:
/etc/inittabSelección del nivel de ejecución por defectoid: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:
/etc/inittabRunlevel definitionsl0: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
The line that defines level 3, again, uses the openrc script to start the services (now with argument default). Again note that the argument of openrc is the same as the subdirectory from /etc/runlevels/.
When openrc has finished, init decides what virtual consoles it should activate and what commands need to be run at each console:
/etc/inittabDefinición de terminalesc1: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
The scripts that the openrc process starts are called init scripts. Each script in /etc/init.d/ can be executed with the arguments start, stop, restart, zap, status, ineed, iuse, iwant, needsme, usesme, or wantsme.
Para iniciar, parar o reiniciar un servicio (y sus respectivas dependencias), deben usarse start, stop y restart:
root #/etc/init.d/postfix startSolo 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 #/etc/init.d/postfix --nodeps stopSi desea ver el estado de un servicio (iniciado, parado, ...) puede usar el parámetro status:
root #/etc/init.d/postfix statusSi la respuesta a status indica que el servicio está corriendo, pero realmente no es así, puede reajustarlo manualmente con el parámetro zap:
root #/etc/init.d/postfix zapPara preguntar por las dependencias que tiene un servicio, puede usar iuse o ineed. Con ineed puede ver qué servicios son realmente necesarios para el correcto funcionamiento del servicio nombrado. Por otra parte, el parámetro iuse muestra los servicios que pueden ser usados por el servicio nombrado, pero que no son requeridos para su correcto funcionamiento.
root #/etc/init.d/postfix ineedDe igual manera, puede indagar que servicios requieren el servicio nombrado (needsme) o cuáles pueden usarlo (usesme):
root #/etc/init.d/postfix needsmeActualizando 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ñadiendo y quitando 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 defaultLa orden rc-update -v show mostrará todos los guiones de inicio con los niveles de ejecución donde ejecutarán:
root #rc-update -v showEs posible ejecutar también rc-update show (sin -v) simplemente para ver los guiones de inicio activos y sus respectivos niveles de ejecución.
Configuración de servicios
¿Por qué requerimos 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:
/etc/conf.d/apache2Ejemplo de opciones para el guión de inicio apache2APACHE2_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).
Escribiendo guiones de inicio
Is it necessary?
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 use el guión de inicio suministrado por el servicio si no está explícitamente escrito para Gentoo: los guiones de inicio de Gentoo ¡No son compatibles con los de las demás distribuciones!. ¡Siempre que las otras distribuciones no estén utilizando OpenRC!
Esquema
El esquema básico de un guión de inicio se muestra a continuación.
#!/sbin/openrc-run depend() { # (Dependency information) } start() { # (Commands necessary to start the service) } stop() { # (Commands necessary to stop the service) }
#!/sbin/openrc-run command=/usr/bin/foo command_args="${foo_args} --bar" pidfile=/var/run/foo.pid name="FooBar Daemon" description="FooBar is a daemon that drinks" extra_started_commands="drink" description_drink="Opens mouth and reflexively swallows" depend() { # (Dependency information) } start_pre() { # (Commands necessary to prepare to start the service) # Ensure that our dirs are correct checkpath --directory --owner foo:foo --mode 0775 \ /var/run/foo /var/cache/foo } stop_post() { # (Commands necessary to clean up after the service) # Clean any spills rm -rf /var/cache/foo/* } drink() { ebegin "Starting to drink" ${command} --drink beer eend $? "Failed to drink any beer :(" }
Cualquier guión de inicio requiere la definición de la función start(). El resto de secciones son opcionales.
Dependencias
Existen dos ajustes relacionados con las dependencias que puede definir y que influyen en el arranque o secuenciación de los guiones de inicio: 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
useinforman 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íause loggerouse 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
needes 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 definebefore 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,
afterinforma 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:
/etc/init.d/postfixInformación de dependencias del servicio poxfixdepend() { 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)
Controlando el orden
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.
/etc/init.d/portmapInformación de dependencias del servicio portmapdepend() { 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.
depend() { before * }
Si su servicio debe escribir a discos locales, debe necesitar localmount. Si escribe algo en /var/run/ como un archivo pid, entonces debería comenzar 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:
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.
Another notable setting used in the above example is to check the contents of the RC_CMD variable. Unlike the previous init script system, the newer OpenRC system does not support script-specific restart functionality. Instead, the script needs to check the contents of the RC_CMD variable to see if a function (be it start() or stop()) is called as part of a restart or not.
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.
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:
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-daemonLa 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ñadiendo 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 la variable extra_commands 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 - Command is available with the service in any state
- extra_started_commands - Command is available when the service is started
- extra_stopped_commands - Command is available when the service is stopped
extra_commands="restartdelay" restartdelay() { stop sleep 3 # Esperar 3 segundos antes de iniciarse de nuevo start }
¡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.
Cambiando el comportamiento del nivel de ejecución
Who might benefit
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.
Utilizando 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/offlineAñ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:
/etc/rc.confHabilitando hotplugging en la interfaz WLANrc_hotplug="net.wlan !net.*"
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.
Utilizando 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. Algunos usuarios (especialmente aquellos nuevos en Linux) encuentran esto un poco extraño o inmanejable. Sin embargo esto no es cierto: usando variables de entorno hace que cualquiera pueda cambiar una opción de configuración para una o más aplicaciones fácilmente.
Ejemplos Importantes
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. |
| CONFIG_PROTECT_MASK | Esta variable una lista de directorios separados por espacio los cuales no deben ser protegidos por Portage durante las actualizaciones. |
A continuación puedes encontrar ejemplos de definiciones para todas estas variables:
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" 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" CONFIG_PROTECT_MASK="/etc/gconf"
Definiendo variables globalmente
El directorio /etc/env.d
Para centralizar la definición de estas variables, Gentoo introduce el directorio /etc/env.d/. Dentro de este directorio se encuentran varios ficheros como por ejemplo 00basic, 05gcc, etc. los cuales contienen las variables necesarias para la aplicación de la cual llevan el nombre.
Por ejemplo, al instalar gcc, un fichero llamado 05gcc que contiene la definición de las siguientes variables, fue creado por el ebuild:
/etc/env.d/05gccVariables establecidas por defecto con gccPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info" CC="gcc" CXX="g++" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
Otras distribuciones le piden modificar o añadir definiciones de variables de entorno semejantes en /etc/profile o en otros sitios. Por otro lado, Gentoo nos hace (y a Portage también) más fácil mantener y manejar las variables de entorno sin tener que prestar atención a los numerosos ficheros que pueden contenerlas.
Por ejemplo, cuando gcc es actualizado, también es actualizado el fichero /etc/env.d/05gcc sin ser necesaria ninguna interacción por parte del usuario.
Esto no solo beneficia a Portage, sino también al usuario. En ocasiones se podrá pedir establecer cierta variable de entorno para todo el sistema. Como ejemplo, tomamos la variable http_proxy. En lugar de perder el tiempo con /etc/profile, puede crear el fichero (/etc/env.d/99local) e introducir la(s) definición(es) en él:
/etc/env.d/99localAsignando una variable globalmente=bashhttp_proxy="proxy.server.com:8080"
Usando el mismo fichero para todas las variables, se obtiene una visión rápida de las variables que hay definidas para uno mismo.
El guión env-update
Varios archivos de /etc/env.d/ definen la variable PATH. esto no es un error: cuando se ejecuta la orden env-update, ésta concatenará las múltiples definiciones antes de actualizar las variables de entorno, haciendo más fácil a los paquetes (o usuarios) añadir sus propias opciones en las 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.
00basic 99kde-env 99local
+-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"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/profileLa 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.
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.Definiendo 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:
~/.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 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"
Warning: Display title "Gentoo Linux amd64 Manual de Gentoo: Trabajar con Gentoo" overrides earlier display title "Handbook:AMD64/Full/Working/es".