Manual Gentoo Linux amd64: Trabajar con Gentoo

Welcome to Portage

Portage is one of Gentoo's most notable innovations in software management. With its high flexibility and enormous amount of features it is frequently seen as the best software management tool available for Linux.

Portage is completely written in Python and Bash and therefore fully visible to the users as both are scripting languages.

Most users will work with Portage through the emerge tool. This chapter is not meant to duplicate the information available from the emerge man page. For a complete rundown of emerge's options, please consult the man page:

user $man emerge

Gentoo repository

Ebuilds

When Gentoo's documentation talks about packages, it means software titles that are available to the Gentoo users through the Gentoo repository. This repository is a collection of ebuilds, files that contain all information Portage needs to maintain software (install, search, query, etc.). These ebuilds reside in /var/db/repos/gentoo by default.

Whenever someone asks Portage to perform some action regarding software titles, it will use the ebuilds on the system as a base. It is therefore important to regularly update the ebuilds on the system so Portage knows about new software, security updates, etc.

Updating the Gentoo repository

The Gentoo repository is usually updated with rsync, a fast incremental file transfer utility. Updating is fairly simple as the emerge command provides a front-end for rsync:

root #emerge --sync

Sometimes firewall restrictions apply that prevent rsync from contacting the mirrors. In this case, the Gentoo repository can be updated via daily generated snapshots. The emerge-webrsync tool automatically fetches and installs the latest snapshot on the system:

root #emerge-webrsync

Maintaining software

Searching for software

There are multiple ways to search through the Gentoo repository for software. One way is through emerge itself. By default, emerge --search returns the names of packages whose title matches (either fully or partially) the given search term.

For instance, to search for all packages who have "pdf" in their name:

user $emerge --search pdf

To search through the descriptions as well, use the --searchdesc (or -S) option:

user $emerge --searchdesc pdf

Notice that the output returns a lot of information. The fields are clearly labelled so we won't go further into their meanings:

CÓDIGO Example output for a search command

*  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

Installing software

When a software title has been found, then the installation is just one emerge command away. For instance, to install gnumeric:

root #emerge --ask app-office/gnumeric

Since many applications depend on each other, any attempt to install a certain software package might result in the installation of several dependencies as well. Don't worry, Portage handles dependencies well. To find out what Portage would install, add the --pretend option. For instance:

root #emerge --pretend gnumeric

To do the same, but interactively choose whether or not to proceed with the installation, add the --ask flag:

root #emerge --ask gnumeric

During the installation of a package, Portage will download the necessary source code from the Internet (if necessary) and store it by default in /var/cache/distfiles/. After this it will unpack, compile and install the package. To tell Portage to only download the sources without installing them, add the --fetchonly option to the emerge command:

root #emerge --fetchonly gnumeric

Finding installed package documentation

Many packages come with their own documentation. Sometimes, the doc USE flag determines whether the package documentation should be installed or not. To see if the doc USE flag is used by a package, use emerge -vp category/package:

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

The best way of enabling the doc USE flag is doing it on a per-package basis via /etc/portage/package.use, so that only the documentation for the wanted packages is installed. For more information read the USE flags section.

Once the package installed, its documentation is generally found in a subdirectory named after the package in the /usr/share/doc/ directory:

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

A more sure way to list installed documentation files is to use equery's --filter option. equery is used to query Portage's database and comes as part of the app-portage/gentoolkit package:

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

The --filter option can be used with other rules to view the install locations for many other types of files. Additional functionality can be reviewed in equery's man page: man 1 equery.

Removing software

To safely remove software from a system, use emerge --deselect. This will tell Portage a package is no longer required and it is eligible for cleaning through --depclean.

root #emerge --deselect gnumeric

When a package is no longer selected, the package and its dependencies that were installed automatically when it was installed are still left on the system. To have Portage locate all dependencies that can now be removed, use emerge's --depclean functionality, which is documented later.

Updating the system

To keep the system in perfect shape (and not to mention install the latest security updates) it is necessary to update the system regularly. Since Portage only checks the ebuilds in the Gentoo repository, the first thing to do is to update this repository using emerge --sync. Then the system can be updated using emerge --deep --update @world.

Portage will, with --deep, search for newer versions of the applications that are installed. Without --deep, it will only verify the versions for the applications that are explicitly installed (the applications listed in /var/lib/portage/world) - it does not thoroughly check their dependencies. This option should almost always therefore be used:

root #emerge --update --deep @world

The standard upgrade command should include --changed-use or --newuse because of possible changes within the repository's profiles, or if the USE settings of the system have been altered. Portage will then verify if the change requires the installation of new packages or recompilation of existing ones:

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

Metapackages

Some packages in the Gentoo repository don't have any real content but are used to install a collection of packages. For instance, the kde-plasma/plasma-meta package will install the KDE Plasma desktop on the system by pulling in various Plasma-related packages as dependencies.

To remove such a package from the system, running emerge --deselect on the package will not have much effect since the dependencies for the package remain on the system.

Portage has the functionality to remove orphaned dependencies as well, but since the availability of software is dynamically dependent it is important to first update the entire system fully, including the new changes applied when changing USE flags. After this one can run emerge --depclean to remove the orphaned dependencies. When this is done, it might be necessary to rebuild the applications that were dynamically linked to the now-removed software titles but don't require them anymore, although recently support for this has been added to Portage.

All this is handled with the following two commands:

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

root #emerge --ask --depclean

Licenses

Beginning with Portage version 2.1.7, it is possible to accept or reject software installation based on its license. All packages in the tree contain a LICENSE entry in their ebuilds. Running emerge --search category/package will show the package's license.

Importante
As a disclaimer and limitation of liability, the LICENSE variable in an ebuild is merely a guideline for Gentoo developers and users. It is not a legal statement or a guarantee that it will reflect the license of every file installed by an ebuild. It should not be relied upon for a completely accurate legal representation of all files provided by a package. To gain assurance, system administrators should perform an in-depth check of each file installed by a package for proper licensing alignment and/or compliance. If a discrepancy is found in the ebuild, please file a bug to suggest a change to the value(s) assigned to the ebuild's LICENSE variable.

By default, Portage permits licenses that are explicitly approved by the Free Software Foundation, the Open Source Initiative, or that follow the Free Software Definition.

The variable that controls permitted licenses is called ACCEPT_LICENSE, which can be set in the /etc/portage/make.conf file. In the next example, this default value is shown:

ARCHIVO /etc/portage/make.confThe default ACCEPT_LICENSE setting

ACCEPT_LICENSE="-* @FREE"

With this configuration, packages with a free software or documentation license will be installable. Non-free software will not be installable.

It is possible to set ACCEPT_LICENSE globally in /etc/portage/make.conf, or to specify it on a per-package basis in the /etc/portage/package.license file.

For example, to allow the google-chrome license for the www-client/google-chrome package, add the following to /etc/portage/package.license:

ARCHIVO /etc/portage/package.licenseAccepting the google-chrome license for the google-chrome package

www-client/google-chrome google-chrome

This permits the installation of the www-client/google-chrome package, but prohibits the installation of the www-plugins/chrome-binary-plugins package, even though it has the same license.

Or to allow the often-needed sys-kernel/linux-firmware:

ARCHIVO /etc/portage/package.licenseAccepting the licenses for the linux-firmware package

# Accepting the license for linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable

# Accepting any license that permits redistribution
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

Importante
Licenses are stored in /var/db/repos/gentoo/licenses/ directory, and license groups are kept in /var/db/repos/gentoo/profiles/license_groups file. The first entry of each line in CAPITAL letters is the name of the license group, and every entry after that is an individual license.

License groups defined in the ACCEPT_LICENSE variable are prefixed with an @ sign. A possible setting (which was the previous Portage default) is to allow all licenses, except End User License Agreements (EULAs) that require reading and signing an acceptance agreement. To accomplish this, accept all licenses (using *) and then remove the licenses in the EULA group as follows:

ARCHIVO /etc/portage/make.confAccept all licenses except EULAs

ACCEPT_LICENSE="* -@EULA"

Note that this setting will also accept non-free software and documentation.

When Portage is complaining

Terminology

As stated before, Portage is extremely powerful and supports many features that other software management tools lack. To understand this, we explain a few aspects of Portage without going into too much detail.

With Portage different versions of a single package can coexist on a system. While other distributions tend to name their package to those versions (like gtk+2 and gtk+3) Portage uses a technology called SLOTs. An ebuild declares a certain SLOT for its version. Ebuilds with different SLOTs can coexist on the same system. For instance, the gtk+ package has ebuilds with SLOT="2" and SLOT="3".

There are also packages that provide the same functionality but are implemented differently. For instance, metalogd, sysklogd, and syslog-ng are all system loggers. Applications that rely on the availability of "a system logger" cannot depend on, for instance, metalogd, as the other system loggers are as good a choice as any. Portage allows for virtuals: each system logger is listed as an "exclusive" dependency of the logging service in the logger virtual package of the virtual category, so that applications can depend on the virtual/logger package. When installed, the package will pull in the first logging package mentioned in the package, unless a logging package was already installed (in which case the virtual is satisfied).

Software in the Gentoo repository can reside in different branches. By default the system only accepts packages that Gentoo deems stable. Most new software titles, when committed, are added to the testing branch, meaning more testing needs to be done before it is marked as stable. Although the ebuilds for those software are in the Gentoo repository, Portage will not update them before they are placed in the stable branch.

Some software is only available for a few architectures. Or the software doesn't work on the other architectures, or it needs more testing, or the developer that committed the software to the Gentoo repository is unable to verify if the package works on different architectures.

Each Gentoo installation also adheres to a certain profile which contains, amongst other information, the list of packages that are required for a system to function normally.

Blocked packages

CÓDIGO Portage warning about blocked packages

[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

Ebuilds contain specific fields that inform Portage about its dependencies. There are two possible dependencies: build dependencies, declared in the DEPEND variable and run-time dependencies, likewise declared in RDEPEND. When one of these dependencies explicitly marks a package or virtual as being not compatible, it triggers a blockage.

While recent versions of Portage are smart enough to work around minor blockages without user intervention, occasionally such blockages need to be resolved manually.

To fix a blockage, users can choose to not install the package or unmerge the conflicting package first. In the given example, one can opt not to install x11-wm/i3 or to remove x11-wm/i3-gaps first. It is usually best to simply tell Portage the package is no longer desired, with emerge --deselect x11-wm/i3-gaps, for example, to remove it from the world file rather than removing the package itself forcefully.

Sometimes there are also blocking packages with specific atoms, such as <media-video/mplayer-1.0_rc1-r2. In this case, updating to a more recent version of the blocking package could remove the block.

It is also possible that two packages that are yet to be installed are blocking each other. In this rare case, try to find out why both would need to be installed. In most cases it is sufficient to do with one of the packages alone. If not, please file a bug on Gentoo's bug tracking system.

Masked packages

CÓDIGO Portage warning about masked packages

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

CÓDIGO Portage warning about masked packages - reason

!!! 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))

When trying to install a package that isn't available for the system, this masking error occurs. Users should try installing a different application that is available for the system or wait until the package is marked as available. There is always a reason why a package is masked:

Reason for mask	Description
~arch keyword	The application is not tested sufficiently to be put in the stable branch. Wait a few days or weeks and try again.
-arch keyword or -* keyword	The application does not work on the target architecture. If this is not the case, then please file a bug.
missing keyword	The application has not yet been tested on the target architecture. Ask the architecture porting team to test the package or test it for them and report the findings on Gentoo's Bugzilla website. See /etc/portage/package.accept_keywords and Accepting a keyword for a single package.
package.mask	The package has been found corrupt, unstable or worse and has been deliberately marked as do-not-use.
profile	The package has been found not suitable for the current profile. The application might break the system if it is installed or is just not compatible with the profile currently in use.
license	The package's license is not compatible with the ACCEPT_LICENSE value. Permit its license or the right license group by setting it in /etc/portage/make.conf or in /etc/portage/package.license.

Necessary USE flag changes

CÓDIGO Portage warning about USE flag change requirement

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

The error message might also be displayed as follows, if --autounmask isn't set:

CÓDIGO Portage error about USE flag change requirement

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])

Such warning or error occurs when a package is requested for installation which not only depends on another package, but also requires that that package is built with a particular USE flag (or set of USE flags). In the given example, the package app-text/feelings needs to be built with USE="test", but this USE flag is not set on the system.

To resolve this, either add the requested USE flag to the global USE flags in /etc/portage/make.conf, or set it for the specific package in /etc/portage/package.use.

Missing dependencies

CÓDIGO Portage warning about missing dependency

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.

The application to install depends on another package that is not available for the system. Please check Bugzilla if the issue is known and if not, please report it. Unless the system is configured to mix branches, this should not occur and is therefore a bug.

Ambiguous ebuild name

CÓDIGO Portage warning about ambiguous ebuild names

[ 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.

The application that is selected for installation has a name that corresponds with more than one package. Supply the category name as well to resolve this. Portage will inform the user about possible matches to choose from.

Circular dependencies

CÓDIGO Portage warning about circular dependencies

!!! 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

Two (or more) packages to install depend on each other and can therefore not be installed. This is most likely a bug in one of the packages in the Gentoo repository. Please re-sync after a while and try again. It might also be beneficial to check Bugzilla to see if the issue is known and if not, report it.

Fetch failed

CÓDIGO Portage warning about fetch failed

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

Portage was unable to download the sources for the given application and will try to continue installing the other applications (if applicable). This failure can be due to a mirror that has not synchronized correctly or because the ebuild points to an incorrect location. The server where the sources reside can also be down for some reason.

Retry after one hour to see if the issue still persists.

System profile protection

CÓDIGO Portage warning about profile-protected package

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

The user has asked to remove a package that is part of the system's core packages. It is listed in the profile as required and should therefore not be removed from the system.

Digest verification failure

CÓDIGO Digest verification failure

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

This is a sign that something is wrong with the Gentoo repository - often, caused by a mistake made when committing an ebuild to the Gentoo ebuild repository.

When the digest verification fails, do not try to re-digest the package personally. Running ebuild foo manifest will not fix the problem; it quite possibly could make it worse.

Instead, wait an hour or two for the repository to settle down. It is likely that the error was noticed right away, but it can take a little time for the fix to trickle down the rsync mirrors. Check Bugzilla and see if anyone has reported the problem yet or ask around on #gentoo (webchat) (IRC). If not, go ahead and file a bug for the broken ebuild.

Once the bug has been fixed, re-sync the Gentoo ebuild repository to pick up the fixed digest.

Importante
Be careful to not sync the Gentoo ebuild repository more than once a day. As stated in the official Gentoo netiquette policy (as well as when running emerge --sync), users who sync too often will be soft-banned from additional syncs for a time. Abusers who repeatedly fail to follow this policy may be hard-banned. Unless absolutely necessary it is often best to wait for a 24 hours period to sync so that re-synchronization does not overload Gentoo's rsync mirrors.

¿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 (/var/db/repos/gentoo/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:

ARCHIVO /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:

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

media-video/vlc bluray

Consejo
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):

ARCHIVO /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.

Importante
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.

Advertencia
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:

ARCHIVO /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.

ARCHIVO ~/.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:

ARCHIVO /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:

ARCHIVO /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.

Importante
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

Importante
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:

ARCHIVO /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:

ARCHIVO /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:

ARCHIVO /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:

ARCHIVO /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:

ARCHIVO /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

Nota
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:

ARCHIVO /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.

CÓDIGO 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)
}

CÓDIGO 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:

ARCHIVO /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.

ARCHIVO /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.

CÓDIGO 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:

CÓDIGO 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:

CÓDIGO 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.

Nota
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.

CÓDIGO 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:

CÓDIGO 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

CÓDIGO 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
}

Importante
¡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:

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

rc_hotplug="net.wlan !net.*"

Nota
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:

CÓDIGO 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:

ARCHIVO /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:

ARCHIVO /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.

CÓDIGO 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

Nota
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.

Importante
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:

ARCHIVO ~/.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"