1.1 Gestión de software con Guix

Guix proporciona una interfaz de gestión de paquetes de línea de ordenes (see Gestión de paquetes), un conjunto de utilidades de línea de órdenes (see Utilidades), así como interfaces programáticas Scheme (see Interfaz programática). Su daemon de construcción es responsable de la construcción de paquetes en delegación de las usuarias (see Preparación del daemon) y de la descarga de binarios preconstruidos de fuentes autorizadas (see Sustituciones)

Guix incluye definiciones de paquetes para muchos paquetes GNU y no-GNU, todos los cuales respetan la libertad de computación de la usuaria. Es extensible: las usuarias pueden escribir sus propias definiciones de paquetes (see Definición de paquetes) y hacerlas disponibles como módulos independientes de paquetes (see Módulos de paquetes). También es personalizable: las usuarias pueden derivar definiciones de paquetes especializadas de las existentes, inclusive desde la línea de órdenes (see Opciones de transformación de paquetes).

En su implementación, Guix utiliza la disciplina de gestión de paquetes funcional en la que Nix fue pionero (see Reconocimientos). En Guix, el proceso de construcción e instalación es visto como una función, en el sentido matemático. Dicha función toma entradas, como los guiones de construcción, un compilador, unas bibliotecas y devuelve el paquete instalado. Como función pura, su resultado únicamente depende de sus entradas—por ejemplo, no puede hacer referencia a software o guiones que no fuesen pasados explícitamente como entrada. Una función de construcción siempre produce el mismo resultado cuando se le proporciona un conjunto de entradas dado. No puede modificar el entorno del sistema que la ejecuta de ninguna forma; por ejemplo, no puede crear, modificar o borrar archivos fuera de sus directorios de construcción e instalación. Esto se consigue ejecutando los procesos de construcción en entornos aislados (o contenedores), donde únicamente sus entradas explícitas son visibles.

El resultado de las funciones de construcción de paquetes es almacenado en la caché en el sistema de archivos, en un directorio especial llamado el almacén (see El almacén). Cada paquete se instala en un directorio propio en el almacén—por defecto, bajo /gnu/store. El nombre del directorio contiene el hash de todas las entradas usadas para construir el paquete; por tanto, cambiar una entrada resulta en un nombre de directorio distinto.

Esta aproximación es el cimiento de las avanzadas características de Guix: capacidad para la actualización transaccional y vuelta-atrás de paquetes, instalación en el ámbito de la usuaria y recolección de basura de paquetes (see Características).

1.2 Distribución GNU

Guix viene con una distribución del sistema GNU consistente en su totalidad de software libre³. La distribución puede instalarse independientemente (see Instalación del sistema), pero también es posible instalar Guix como un gestor de paquetes sobre un sistema GNU/Linux existente (see Instalación). Para distinguir entre las dos opciones, nos referimos a la distribución independiente como el sistema Guix.

La distribución proporciona paquetes principales de GNU como GNU libc, GCC y Binutils, así como muchas aplicaciones GNU y no-GNU. La lista completa de paquetes disponibles se puede explorar en línea o ejecutando guix package (see Invocación de guix package):

guix package --list-available

Nuestro objetivo es proporcionar una distribución práctica con 100% software libre basada en Linux y otras variantes de GNU, con un enfoque en la promoción y la alta integración de componentes GNU, y un énfasis en programas y herramientas que ayuden a las usuarias a ejercitar esa libertad.

Actualmente hay paquetes disponibles para las siguientes plataformas:

x86_64-linux

Arquitectura x86_64 de Intel/AMD, con núcleo Linux-Libre.

i686-linux

Arquitectura de 32-bits Intel (IA32), con núcleo Linux-Libre.

armhf-linux

Arquitectura ARMv7-A con coma flotante hardware, Thumb-2 y NEON, usando la interfaz binaria de aplicaciones (ABI) EABI con coma flotante hardware, y con el núcleo Linux-Libre.

aarch64-linux

procesadores ARMv8-A de 64 bits little-endian, con el núcleo Linux-Libre.

i586-gnu

GNU/Hurd en la arquitectura Intel de 32 bits (IA32).

Esta configuración es experimental y se encuentra en desarrollo. La forma más fácil de probarla es configurando una instancia del servicio hurd-vm-service-type en su máquina GNU/Linux (see hurd-vm-service-type). ¡See Contribuir para informarse sobre cómo ayudar!

mips64el-linux (unsupported)

little-endian 64-bit MIPS processors, specifically the Loongson series, n32 ABI, and Linux-Libre kernel. This configuration is no longer fully supported; in particular, there is no ongoing work to ensure that this architecture still works. Should someone decide they wish to revive this architecture then the code is still available.

powerpc-linux (unsupported)

big-endian 32-bit PowerPC processors, specifically the PowerPC G4 with AltiVec support, and Linux-Libre kernel. This configuration is not fully supported and there is no ongoing work to ensure this architecture works.

powerpc64le-linux

little-endian 64-bit Power ISA processors, Linux-Libre kernel. This includes POWER9 systems such as the RYF Talos II mainboard. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (see Sustituciones), and some packages may fail to build (see Tracking Bugs and Changes). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved!

riscv64-linux

little-endian 64-bit RISC-V processors, specifically RV64GC, and Linux-Libre kernel. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (see Sustituciones), and some packages may fail to build (see Tracking Bugs and Changes). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved!

Con el sistema Guix, declara todos los aspectos de la configuración del sistema y Guix se hace cargo de instanciar la configuración de manera transaccional, reproducible y sin estado global (see Configuración del sistema). El sistema Guix usa el núcleo Linux-libre, el sistema de inicialización Shepherd (see Introduction in The GNU Shepherd Manual), las conocidas utilidades y herramientas de compilación GNU, así como el entorno gráfico o servicios del sistema de su elección.

Guix System is available on all the above platforms except mips64el-linux, powerpc-linux, powerpc64le-linux and riscv64-linux.

Para información sobre el transporte a otras arquitecturas o núcleos, see Transportar a una nueva plataforma.

La construcción de esta distribución es un esfuerzo cooperativo, ¡y esta invitada a unirse! See Contribuir, para información sobre cómo puede ayudar.

2.1 Instalación binaria

This section describes how to install Guix from a self-contained tarball providing binaries for Guix and for all its dependencies. This is often quicker than installing from source, described later (see Construcción desde Git).

Importante: This section only applies to systems without Guix. Following it for existing Guix installations will overwrite important system files.

Some GNU/Linux distributions, such as Debian, Ubuntu, and openSUSE provide Guix through their own package managers. The version of Guix may be older than 2a6d964 but you can update it afterwards by running ‘guix pull’.

We advise system administrators who install Guix, both from the installation script or via the native package manager of their foreign distribution, to also regularly read and follow security notices, as shown by guix pull.

For Debian or derivatives such as Ubuntu or Trisquel, call:

sudo apt install guix

Likewise, on openSUSE:

sudo zypper install guix

If you are running Parabola, after enabling the pcr (Parabola Community Repo) repository, you can install Guix with:

sudo pacman -S guix

The Guix project also provides a shell script, guix-install.sh, which automates the binary installation process without use of a foreign distro package manager⁵. Use of guix-install.sh requires Bash, GnuPG, GNU tar, wget, and Xz.

The script guides you through the following:

• Downloading and extracting the binary tarball
• Setting up the build daemon
• Making the ‘guix’ command available to non-root users
• Configuring substitute servers

As root, run:

# cd /tmp
# wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
# chmod +x guix-install.sh
# ./guix-install.sh

The script to install Guix is also packaged in Parabola (in the pcr repository). You can install and run it with:

sudo pacman -S guix-installer
sudo guix-install.sh

Nota: By default, guix-install.sh will configure Guix to download pre-built package binaries, called substitutes (see Sustituciones), from the project’s build farms. If you choose not to permit this, Guix will build everything from source, making each installation and upgrade very expensive. See Sobre la confianza en binarios for a discussion of why you may want to build packages from source.

To use substitutes from bordeaux.guix.gnu.org, ci.guix.gnu.org or a mirror, you must authorize them. For example,

# guix archive --authorize < \
     ~root/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub
# guix archive --authorize < \
     ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub

When you’re done installing Guix, see Configuración de la aplicación for extra configuration you might need, and Empezando for your first steps!

Nota: El archivador de la instalación binaria puede ser (re)producido y verificado simplemente ejecutando la siguiente orden en el árbol de fuentes de Guix:

make guix-binary.sistema.tar.xz

... que a su vez ejecuta:

guix pack -s sistema --localstatedir \
  --profile-name=current-guix guix

See Invocación de guix pack, para más información sobre esta útil herramienta.

Should you eventually want to uninstall Guix, run the same script with the --uninstall flag:

./guix-install.sh --uninstall

With --uninstall, the script irreversibly deletes all the Guix files, configuration, and services.

2.2 Preparación del daemon

During installation, the build daemon that must be running to use Guix has already been set up and you can run guix commands in your terminal program, see Empezando:

guix build hello

If this runs through without error, feel free to skip this section. You should continue with the following section, Configuración de la aplicación.

However, now would be a good time to replace outdated daemon versions, tweak it, perform builds on other machines (see Uso de la facilidad de delegación de trabajo), or start it manually in special environments like “chroots” (see Chrooting into an existing system) or WSL (not needed for WSL images created with Guix, see wsl2-image-type). If you want to know more or optimize your system, this section is worth reading.

Operaciones como la construcción de un paquete o la ejecución del recolector de basura son realizadas por un proceso especializado, el daemon de construcción, en delegación de sus clientes. Únicamente el daemon puede acceder al almacén y su base de datos asociada. Por tanto, cualquier operación que manipula el almacén se realiza a través del daemon. Por ejemplo, las herramientas de línea de órdenes como guix package y guix build se comunican con el daemon (via llamadas a procedimientos remotos) para indicarle qué hacer.

The following sections explain how to prepare the build daemon’s environment. See Sustituciones for how to allow the daemon to download pre-built binaries.

• Configuración del entorno de construcción
• Uso de la facilidad de delegación de trabajo
• Soporte de SELinux

# groupadd --system guixbuild
# for i in $(seq -w 1 10);
  do
    useradd -g guixbuild -G guixbuild           \
            -d /var/empty -s $(which nologin)   \
            -c "Guix build user $i" --system    \
            guixbuilder$i;
  done

# guix-daemon --build-users-group=guixbuild

(list (build-machine
        (name "ochentayseis.example.org")
        (systems (list "x86_64-linux" "i686-linux"))
        (host-key "ssh-ed25519 AAAAC3Nza…")
        (user "rober")
        (speed 2.))     ;¡increíblemente rápida!

      (build-machine
        (name "armeight.example.org")
        (systems (list "aarch64-linux"))
        (host-key "ssh-rsa AAAAB3Nza…")
        (user "alice")

        ;; Remember 'guix offload' is spawned by
        ;; 'guix-daemon' as root.
        (private-key "/root/.ssh/identity-for-guix")))

ssh build-machine guix repl --version

# guix archive --generate-key

# guix archive --authorize < clave-publica-maestra.txt

# guix offload test

# guix offload test otras-maquinas.scm

# guix offload test maquinas.scm '\.gnu\.org$'

# guix offload status

semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil

mount -o remount,rw /gnu/store
restorecon -R /gnu /var/guix

systemctl restart guix-daemon

ps -Zax | grep guix-daemon

2.3 Invocación de guix-daemon

El programa guix-daemon implementa toda la funcionalidad para acceder al almacén. Esto incluye iniciar procesos de construcción, ejecutar el recolector de basura, comprobar la disponibilidad de un resultado de construcción, etc. Normalmente se ejecuta como root así:

# guix-daemon --build-users-group=guixbuild

This daemon can also be started following the systemd “socket activation” protocol (see make-systemd-constructor in The GNU Shepherd Manual).

Para detalles obre como configurarlo, see Preparación del daemon.

Por defecto, guix-daemon inicia los procesos de construcción bajo distintos UIDs, tomados del grupo de construcción especificado con --build-users-group. Además, cada proceso de construcción se ejecuta en un entorno “chroot” que únicamente contiene el subconjunto del almacén del que depende el proceso de construcción, como especifica su derivación (see derivación), más un conjunto específico de directorios del sistema. Por defecto, estos directorios contienen /dev y /dev/pts. Es más, sobre GNU/Linux, el entorno de construcción es un contenedor: además de tener su propio árbol del sistema de archivos, tiene un espacio de nombres de montado separado, su propio espacio de nombres de PID, de red, etc. Esto ayuda a obtener construcciones reproducibles (see Características).

Cuando el daemon realiza una construcción en delegación de la usuaria, crea un directorio de construcción bajo /tmp o bajo el directorio especificado por su variable de entorno TMPDIR. Este directorio se comparte con el contenedor durante toda la construcción, aunque dentro del contenedor el árbol de construcción siempre se llama /tmp/guix-build-nombre.drv-0.

The build directory is automatically deleted upon completion, unless the build failed and the client specified --keep-failed (see --keep-failed).

El daemon espera conexiones y lanza un subproceso por sesión iniciada por cada cliente (una de las sub-órdenes de guix). La orden guix processes le permite tener una visión general de la actividad de su sistema mostrando clientes y sesiones activas. See Invocación de guix processes, para más información.

Se aceptan las siguientes opciones de línea de ordenes:

--build-users-group=grupo

Toma las usuarias de grupo para ejecutar los procesos de construcción (see build users).

--no-substitutes ¶

No usa sustituciones para la construcción de productos. Esto es, siempre realiza las construcciones localmente en vez de permitir la descarga de binarios pre-construidos (see Sustituciones).

Cuando el daemon se está ejecutando con la opción --no-substitutes, los clientes aún pueden activar explícitamente las sustituciones a través de la llamada de procedimiento remoto set-build-options (see El almacén).

--substitute-urls=urls

Consider urls the default whitespace-separated list of substitute source URLs. When this option is omitted, ‘https://bordeaux.guix.gnu.org https://ci.guix.gnu.org’ is used.

Esto significa que las sustituciones puede ser descargadas de urls, mientras estén firmadas por una firma de confianza (see Sustituciones).

See Obtención de sustiticiones desde otros servidores para obtener más información sobre cómo configurar el daemon para obtener sustituciones de otros servidores.

--no-offload

No usa la delegación de construcciones en otras máquinas (see Uso de la facilidad de delegación de trabajo). Es decir, siempre realiza las construcciones de manera local en vez de delegar construcciones a máquinas remotas.

--cache-failures

Almacena en la caché los fallos de construcción. Por defecto, únicamente las construcciones satisfactorias son almacenadas en la caché.

Cuando se usa esta opción, guix gc --list-failures puede usarse para consultar el conjunto de elementos del almacén marcados como fallidos; guix gc --clear-failures borra los elementos del almacén del conjunto de fallos existentes en la caché. See Invocación de guix gc.

--cores=n

-c n

Usa n núcleos de la CPU para construir cada derivación; 0 significa tantos como haya disponibles.

El valor predeterminado es 0, pero puede ser sobreescrito por los clientes, como la opción --cores de guix build (see Invocación de guix build).

El efecto es definir la variable de entorno NIX_BUILD_CORES en el proceso de construcción, el cual puede usarla para explotar el paralelismo interno—por ejemplo, ejecutando make -j$NIX_BUILD_CORES.

--max-jobs=n

-M n

Permite como máximo n trabajos de construcción en paralelo. El valor predeterminado es 1. Fijarlo a 0 significa que ninguna construcción se realizará localmente; en vez de eso, el daemon delegará las construcciones (see Uso de la facilidad de delegación de trabajo), o simplemente fallará.

--max-silent-time=segundos

Cuando la construcción o sustitución permanece en silencio más de segundos, la finaliza e informa de un fallo de construcción.

The default value is 3600 (one hour).

El valor especificado aquí puede ser sobreescrito por clientes (see --max-silent-time).

--timeout=segundos

Del mismo modo, cuando el proceso de construcción o sustitución dura más de segundos, lo termina e informa un fallo de construcción.

The default value is 24 hours.

El valor especificado aquí puede ser sobreescrito por los clientes (see --timeout).

--rounds=N

Construye cada derivación n veces seguidas, y lanza un error si los resultados de las construcciones consecutivas no son idénticos bit-a-bit. Fíjese que esta configuración puede ser sobreescrita por clientes como guix build (see Invocación de guix build).

Cuando se usa conjuntamente con --keep-failed, la salida que difiere se mantiene en el almacén, bajo /gnu/store/…-check. Esto hace fácil buscar diferencias entre los dos resultados.

--debug

Produce salida de depuración.

Esto es útil para depurar problemas en el arranque del daemon, pero su comportamiento puede cambiarse en cada cliente, por ejemplo con la opción --verbosity de guix build (see Invocación de guix build).

--chroot-directory=dir

Añade dir al chroot de construcción.

Hacer esto puede cambiar el resultado del proceso de construcción—por ejemplo si usa dependencias opcionales, que se encuentren en dir, cuando están disponibles, y no de otra forma. Por esa razón, no se recomienda hacerlo. En vez de eso, asegúrese que cada derivación declara todas las entradas que necesita.

--disable-chroot

Desactiva la construcción en un entorno chroot.

No se recomienda el uso de esta opción ya que, de nuevo, podría permitir a los procesos de construcción ganar acceso a dependencias no declaradas. Es necesario, no obstante, cuando guix-daemon se ejecuta bajo una cuenta de usuaria sin privilegios.

--log-compression=tipo

Comprime los logs de construcción de acuerdo a tipo, que puede ser gzip, bzip2 o none.

Unless --lose-logs is used, all the build logs are kept in the localstatedir. To save space, the daemon automatically compresses them with gzip by default.

--discover[=yes|no]

Whether to discover substitute servers on the local network using mDNS and DNS-SD.

This feature is still experimental. However, here are a few considerations.

1. It might be faster/less expensive than fetching from remote servers;
2. There are no security risks, only genuine substitutes will be used (see Verificación de sustituciones);
3. An attacker advertising guix publish on your LAN cannot serve you malicious binaries, but they can learn what software you’re installing;
4. Servers may serve substitute over HTTP, unencrypted, so anyone on the LAN can see what software you’re installing.

It is also possible to enable or disable substitute server discovery at run-time by running:

herd discover guix-daemon on
herd discover guix-daemon off

--disable-deduplication ¶

Desactiva la “deduplicación” automática en el almacén.

Por defecto, los archivos se añaden al almacén “deduplicados” automáticamente: si un nuevo archivo añadido es idéntico a otro que ya se encuentra en el almacén, el daemon introduce el nuevo archivo como un enlace duro al otro archivo. Esto puede reducir notablemente el uso del disco, a expensas de una carga de entrada/salida ligeramente incrementada al finalizar un proceso de construcción. Esta opción desactiva dicha optimización.

--gc-keep-outputs[=yes|no]

Determina si el recolector de basura (GC) debe mantener salidas de las derivaciones vivas.

Cuando se usa yes, el recolector de basura mantendrá las salidas de cualquier derivación viva disponible en el almacén—los archivos .drv. El valor predeterminado es no, lo que significa que las salidas de las derivaciones se mantienen únicamente si son alcanzables desde alguna raíz del recolector de basura. See Invocación de guix gc, para más información sobre las raíces del recolector de basura.

--gc-keep-derivations[=yes|no]

Determina si el recolector de basura (GC) debe mantener derivaciones correspondientes a salidas vivas.

Cuando se usa yes, como es el caso predeterminado, el recolector de basura mantiene derivaciones—es decir, archivos .drv—mientras al menos una de sus salidas está viva. Esto permite a las usuarias seguir la pista de los orígenes de los elementos en el almacén. El uso de no aquí ahorra un poco de espacio en disco.

De este modo, usar --gc-keep-derivations con valor yes provoca que la vitalidad fluya de salidas a derivaciones, y usar --gc-keep-outputs con valor yes provoca que la vitalidad fluya de derivaciones a salidas. Cuando ambas tienen valor yes, el efecto es mantener todos los prerrequisitos de construcción (las fuentes, el compilador, las bibliotecas y otras herramientas de tiempo de construcción) de los objetos vivos del almacén, independientemente de que esos prerrequisitos sean alcanzables desde una raíz del recolector de basura. Esto es conveniente para desarrolladoras ya que evita reconstrucciones o descargas.

--impersonate-linux-2.6

En sistemas basados en Linux, suplanta a Linux 2.6. Esto significa que la llamada del sistema uname del núcleo indicará 2.6 como el número de versión de la publicación.

Esto puede ser útil para construir programas que (habitualmente de forma incorrecta) dependen en el número de versión del núcleo.

--lose-logs

No guarda logs de construcción. De manera predeterminada se almacenan en el directorio localstatedir/guix/log.

--system=sistema

Asume sistema como el tipo actual de sistema. Por defecto es el par de arquitectura/núcleo encontrado durante la configuración, como x86_64-linux.

--listen=destino

Espera conexiones en destino. destino se interpreta como el nombre del archivo del socket de dominio Unix si comienza on / (barra a la derecha). En otro caso, destino se interpreta como un nombre de máquina o un nombre de máquina y puerto a escuchar. Aquí van unos pocos ejemplos:

--listen=/gnu/var/daemon

Espera conexiones en el socket de dominio Unix /gnu/var/daemon, se crea si es necesario.

--listen=localhost ¶

Espera conexiones TCP en la interfaz de red correspondiente a localhost, en el puerto 44146.

--listen=128.0.0.42:1234

Espera conexiones TCP en la interfaz de red correspondiente a 128.0.0.42, en el puerto 1234.

Esta opción puede repetirse múltiples veces, en cuyo caso guix-daemon acepta conexiones en todos los destinos especificados. Las usuarias pueden indicar a los clientes a qué destino conectarse proporcionando el valor deseado a la variable de entorno GUIX_DAEMON_SOCKET (see GUIX_DAEMON_SOCKET).

Nota: El protocolo del daemon no está autentificado ni cifrado. El uso de --listen=dirección es aceptable en redes locales, como clusters, donde únicamente los nodos de confianza pueden conectarse al daemon de construcción. En otros casos donde el acceso remoto al daemon es necesario, recomendamos usar sockets de dominio Unix junto a SSH.

Cuando se omite --listen, guix-daemon escucha conexiones en el socket de dominio Unix que se encuentra en localstatedir/guix/daemon-socket/socket.

2.4 Configuración de la aplicación

Cuando se usa Guix sobre una distribución GNU/Linux distinta al sistema Guix—una distribución distinta—unos pocos pasos adicionales son necesarios para tener todo preparado. Aquí están algunos de ellos.

• Localizaciones
• Selector de servicios de nombres
• Tipografías X11
• Certificados X.509
• Paquetes Emacs

$ guix install glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

(use-modules (gnu packages base))

(define my-glibc-locales
  (make-glibc-utf8-locales
   glibc
   #:locales (list "en_CA" "fr_CA" "ik_CA" "iu_CA" "shs_CA")
   #:name "glibc-canadian-utf8-locales"))

guix install fontconfig
fc-cache -rv

guix install font-adobe-source-han-sans:cn

-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1

xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))

2.5 Actualizar Guix

Para actualizar Guix ejecute:

guix pull

See Invocación de guix pull, para más información.

En una distribución distinta puede actualizar el daemon de construcción ejecutando:

sudo -i guix pull

seguido de (asumiendo que su distribución usa la herramienta de gestión de servicios systemd):

systemctl restart guix-daemon.service

En el Sistema Guix, la actualización del daemon se lleva a cabo con la reconfiguración el sistema (see guix system reconfigure).

3.1 Limitaciones

Consideramos que el sistema Guix está listo para un amplio rango de casos de uso, tanto de servidor como de escritorio. Las garantías que proporciona—actualizaciones transaccionales y vuelta atrás atómica, reproducibilidad—lo convierten en un cimiento sólido.

More and more system services are provided (see Servicios).

Nevertheless, before you proceed with the installation, be aware that some services you rely on may still be missing from version 2a6d964.

Más que una descarga de responsabilidades es una invitación a informar de problemas (¡e historias satisfactorias!), y para unirse a nosotras en su mejora. See Contribuir, para más información.

3.2 Consideraciones sobre el hardware

GNU Guix se enfoca en respetar la libertad de computación de las usuarias. Se construye sobre el núcleo Linux-libre, lo que significa que únicamente funciona hardware para el que existen controladores y firmware libres. Hoy en día, un amplio rango del hardware común funciona con GNU/Linux-libre—desde teclados a tarjetas gráficas a escáneres y controladoras Ethernet. Desafortunadamente, todavía hay áreas donde los fabricantes de hardware deniegan a las usuarias el control de su propia computación, y dicho hardware no funciona en el sistema Guix.

Una de las áreas principales donde faltan controladores o firmware libre son los dispositivos WiFi. Los dispositivos WiFi que se sabe que funcionan incluyen aquellos que usan los chips Atheros (AR9271 y AR7010), que corresponden al controlador ath9k de Linux-libre, y aquellos que usan los chips Broadcom/AirForce (BCM43xx con Wireless-Core Revisión 5), que corresponden al controlador b43-open de Linux-libre. Existe firmware libre para ambos, y está disponible por defecto en el sistema Guix, como parte de %base-firmware (see firmware).

The installer warns you early on if it detects devices that are known not to work due to the lack of free firmware or free drivers.

La Fundación del Software Libre patrocina Respeta Su Libertad (RYF), un programa de certificación para productos hardware que respetan su libertad y su privacidad y se aseguran de que usted tenga el control sobre su dispositivo. Le recomendamos que compruebe la lista de dispositivos certificados RYF.

Otro recurso útil es el sitio web H-Node. Contiene un catálogo de dispositivos hardware con información acerca su funcionalidad con GNU/Linux.

3.3 Instalación desde memoria USB y DVD

Se puede descargar una imagen de instalación ISO-9660 que puede ser escrita en una memoria USB o grabada en un DVD desde ‘https://ftp.gnu.org/gnu/guix/guix-system-install-2a6d964.x86_64-linux.iso’, donde puede sustituir x86_64-linux con uno de los siguientes valores:

x86_64-linux

para un sistema GNU/Linux en CPUs compatibles con la arquitectura de 64-bits de Intel/AMD;

i686-linux

para un sistema GNU/Linux en CPUs compatibles con la arquitectura de 32-bits de Intel.

Asegúrese de descargar el archivo .sig asociado y de verificar la autenticidad de la imagen contra él, más o menos así:

$ wget https://ftp.gnu.org/gnu/guix/guix-system-install-2a6d964.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-2a6d964.x86_64-linux.iso.sig

Si la orden falla porque no dispone de la clave pública necesaria, entonces ejecute esta otra orden para importarla:

$ wget https://sv.gnu.org/people/viewgpg.php?user_id=15145 \
      -qO - | gpg --import -

y vuelva a ejecutar la orden gpg --verify.

Tenga en cuenta que un aviso del tipo “Esta clave no esta certificada con una firma de confianza” es normal.

Esta imagen contiene las herramientas necesarias para una instalación. Está pensada ara ser copiada tal cual a una memoria USB o DVD con espacio suficiente.

• Copiado en una memoria USB
• Grabación en un DVD
• Arranque

dd if=guix-system-install-2a6d964.x86_64-linux.iso of=/dev/sdX
sync

growisofs -dvd-compat -Z /dev/srX=guix-system-install-2a6d964.x86_64-linux.iso

3.4 Preparación para la instalación

Una vez que haya arrancado, puede usar el instalador gráfico guiado, el cual facilita la introducción al sistema (see Instalación gráfica guiada). Alternativamente, si ya es está familiarizada con GNU/Linux y desea más control que el que proporciona el instalador gráfico, puede seleccionar el proceso de instalación “manual” (see Instalación manual).

El instalador gráfico está disponible en TTY1. Puede obtener consolas de administración (“root”) en los TTY 3 a 6 pulsando ctrl-alt-f3, ctrl-alt-f4, etc. TTY2 muestra esta documentación y se puede cambiar a dicha consola con ctrl-alt-f2. La documentación es explorable usando las órdenes del lector Info (see Stand-alone GNU Info). El sistema de instalación ejecuta el daemon GPM para ratones, el cual le permite seleccionar texto con el botón izquierdo y pegarlo con el botón central.

Nota: La instalación requiere acceso a Internet de modo que cualquier dependencia de su configuración de sistema no encontrada pueda ser descargada. Véase la sección “Red” más adelante.

3.5 Instalación gráfica guiada

El instalador gráfico es una interfaz de usuaria basada en texto. Le guiará, con cajas de diálogo, a través de los pasos necesarios para instalar el sistema GNU Guix.

Las primeras cajas de diálogo le permiten configurar el sistema mientras lo usa durante la instalación: puede seleccionar el idioma, la distribución del teclado y configurar la red, la cual se usará durante la instalación. La siguiente imagen muestra el diálogo de configuración de red.

Los siguientes pasos le permitirán particionar su disco duro, como se muestra en la siguiente imagen, elegir si se usarán o no sistemas de archivos cifrados, introducir el nombre de la máquina, la contraseña de root y crear cuentas adicionales, entre otras cosas.

Tenga en cuenta que, en cualquier momento, el instalador le permite salir de la instalación actual y retomarla en un paso previo, como se muestra en la siguiente imagen.

Una vez haya finalizado, el instalador produce una configuración de sistema operativo y la muestra (see Uso de la configuración del sistema). En este punto puede pulsar “OK” y la instalación procederá. En caso de finalización satisfactoria, puede reiniciar con el nuevo sistema y disfrutarlo. ¡See Tras la instalación del sistema para ver cómo proceder a continuación!

3.6 Instalación manual

Esta sección describe como podría instalar “manualmente” el sistema GNU Guix en su máquina. Esta opción requiere familiaridad con GNU/Linux, con el intérprete y con las herramientas de administración comunes. Si piensa que no es para usted, considere el uso del instalador gráfico guiado (see Instalación gráfica guiada).

The installation system provides root shells on TTYs 3 to 6; press ctrl-alt-f3, ctrl-alt-f4, and so on to reach them. It includes many common tools needed to install the system, but is also a full-blown Guix System. This means that you can install additional packages, should you need it, using guix package (see Invocación de guix package).

• Distribución de teclado, red y particionado
• Procedimiento de instalación

loadkeys es

ifconfig -a

ip address

dhclient -v interfaz

ping -c 3 gnu.org

herd set-http-proxy guix-daemon URL

herd start ssh-daemon

cfdisk

parted /dev/sda set 1 esp on

mkfs.fat -F32 /dev/sda1

mkfs.ext4 -L mi-raiz /dev/sda2

cryptsetup luksFormat /dev/sda2
cryptsetup open /dev/sda2 my-partition
mkfs.ext4 -L my-root /dev/mapper/my-partition

mount LABEL=mi-raiz /mnt

mkswap /dev/sda3
swapon /dev/sda3

# Esto son 10GiB de espacio de intercambio. Ajuste "count" para
# cambiar el tamaño.
dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240
# Por seguridad, se le conceden permisos de lectura y escritura
# únicamente a root.
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile

herd start cow-store /mnt

# mkdir /mnt/etc
# cp /etc/configuration/desktop.scm /mnt/etc/config.scm
# nano /mnt/etc/config.scm

guix system init /mnt/etc/config.scm /mnt

3.7 Tras la instalación del sistema

Success, you’ve now booted into Guix System! You can upgrade the system whenever you want by running:

guix pull
sudo guix system reconfigure /etc/config.scm

This builds a new system generation with the latest packages and services.

Now, see Empezando, and join us on #guix on the Libera.Chat IRC network or on guix-devel@gnu.org to share your experience!

3.8 Instalación de Guix en una máquina virtual

Si desea instalar el sistema Guix en una máquina virtual (VM) o en un servidor privado virtual (VPS) en vez de en su preciada máquina, esta sección es para usted.

Si quiere arrancar una VM QEMU para instalar el sistema Guix en una imagen de disco, siga estos pasos:

1. Primero, obtenga y descomprima la imagen de instalación del sistema Guix como se ha descrito previamente (see Instalación desde memoria USB y DVD).
2. Cree una imagen de disco que contendrá el sistema instalado. Para crear una imagen de disco con formato qcow2, use la orden qemu-img:

   qemu-img create -f qcow2 guix-system.img 50G
   

   El archivo que obtenga será mucho menor de 50GB (típicamente menos de 1MB), pero crecerá cuando el dispositivo de almacenamiento virtualizado se vaya llenando.

3. Arranque la imagen de instalación USB en una máquina virtual:

   qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
     -nic user,model=virtio-net-pci -boot menu=on,order=d \
     -drive file=guix-system.img \
     -drive media=cdrom,readonly=on,file=guix-system-install-2a6d964.system.iso
   

   -enable-kvm es opcional, pero mejora el rendimiento significativamente, see Ejecución de Guix en una máquina virtual.

4. Ahora es root en la VM, prosiga con el procedimiento de instalación. See Preparación para la instalación, y siga las instrucciones.

Una vez complete la instalación, puede arrancar el sistema que está en la imagen guix-system.img. See Ejecución de Guix en una máquina virtual, para información sobre cómo hacerlo.

3.9 Construcción de la imagen de instalación

La imagen de instalación descrita anteriormente se construyó usando la orden guix system, específicamente:

guix system image -t iso9660 gnu/system/install.scm

Eche un vistazo a gnu/system/install.scm en el árbol de fuentes, y vea también Invoking guix system para más información acerca de la imagen de instalación.

3.10 Construcción de la imagen de instalación para placas ARM

Muchos dispositivos con procesador ARM necesitan una variante específica del cargador de arranque U-Boot.

Si construye una imagen de disco y el cargador de arranque no está disponible de otro modo (en otra unidad de arranque, etc.), es recomendable construir una imagen que incluya el cargador, específicamente:

guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'

A20-OLinuXino-Lime2 es el nombre de la placa. Si especifica una placa no válida, una lista de placas posibles será mostrada.

5.1 Características

Se asume que ya ha dado sus primeros pasos con Guix (see Empezando) y desea obtener información general sobre cómo funciona la implementación internamente.

Cuando se usa Guix, cada paquete se encuentra en el almacén de paquetes, en su propio directorio—algo que se asemeja a /gnu/store/xxx-paquete-1.2, donde xxx es una cadena en base32.

En vez de referirse a estos directorios, las usuarias tienen su propio perfil, el cual apunta a los paquetes que realmente desean usar. Estos perfiles se almacenan en el directorio de cada usuaria, en $HOME/.guix-profile.

Por ejemplo, alicia instala GCC 4.7.2. Como resultado, /home/alicia/.guix-profile/bin/gcc apunta a /gnu/store/…-gcc-4.7.2/bin/gcc. Ahora, en la misma máquina, rober ha instalado ya GCC 4.8.0. El perfil de rober simplemente sigue apuntando a /gnu/store/…-gcc-4.8.0/bin/gcc—es decir, ambas versiones de GCC pueden coexistir en el mismo sistema sin ninguna interferencia.

La orden guix package es la herramienta central para gestión de paquetes (see Invocación de guix package). Opera en los perfiles de usuaria, y puede ser usada con privilegios de usuaria normal.

La orden proporciona las operaciones obvias de instalación, borrado y actualización. Cada invocación es en realidad una transacción: o bien la operación especificada se realiza satisfactoriamente, o bien nada sucede. Por tanto, si el proceso guix package es finalizado durante una transacción, o un fallo eléctrico ocurre durante la transacción, el perfil de usuaria permanece en su estado previo, y permanece usable.

In addition, any package transaction may be rolled back. So, if, for example, an upgrade installs a new version of a package that turns out to have a serious bug, users may roll back to the previous instance of their profile, which was known to work well. Similarly, the global system configuration on Guix is subject to transactional upgrades and roll-back (see Empezando).

Todos los paquetes en el almacén de paquetes pueden ser eliminados por el recolector de basura. Guix puede determinar a qué paquetes hacen referencia todavía los perfiles de usuarias, y eliminar aquellos que, de forma demostrable, no se haga referencia en ningún perfil (see Invocación de guix gc). Las usuarias pueden también borrar explícitamente generaciones antiguas de su perfil para que los paquetes a los que hacen referencia puedan ser recolectados.

Guix toma una aproximación puramente funcional en la gestión de paquetes, como se describe en la introducción (see Introducción). Cada nombre de directorio de paquete en /gnu/store contiene un hash de todas las entradas que fueron usadas para construir el paquete—compilador, bibliotecas, guiones de construcción, etc. Esta correspondencia directa permite a las usuarias asegurarse que una instalación dada de un paquete corresponde al estado actual de su distribución. Esto también ayuda a maximizar la reproducibilidad de la construcción: gracias al uso de entornos aislados de construcción, una construcción dada probablemente generará archivos idénticos bit-a-bit cuando se realice en máquinas diferentes (see container).

Estos cimientos permiten a Guix ofrecer despliegues transparentes de binarios/fuentes. Cuando un binario pre-construido para un elemento de /gnu/store está disponible para descarga de una fuente externa—una sustitución, Guix simplemente lo descarga y desempaqueta; en otro caso construye el paquete de las fuentes, localmente (see Sustituciones). Debido a que los resultados de construcción son normalmente reproducibles bit-a-bit, las usuarias no tienen que confiar en los servidores que proporcionan sustituciones: pueden forzar una construcción local y retar a las proveedoras (see Invocación de guix challenge).

Control over the build environment is a feature that is also useful for developers. The guix shell command allows developers of a package to quickly set up the right development environment for their package, without having to manually install the dependencies of the package into their profile (see Invoking guix shell).

Todo Guix y sus definiciones de paquetes están bajo control de versiones, y guix pull le permite “viajar en el tiempo” por la historia del mismo Guix (see Invocación de guix pull). Esto hace posible replicar una instancia de Guix en una máquina diferente o en un punto posterior del tiempo, lo que a su vez le permite replicar entornos de software completos, mientras que mantiene un preciso seguimiento de la procedencia del software.

5.2 Invocación de guix package

The guix package command is the tool that allows users to install, upgrade, and remove packages, as well as rolling back to previous configurations. These operations work on a user profile—a directory of installed packages. Each user has a default profile in $HOME/.guix-profile. The command operates only on the user’s own profile, and works with normal user privileges (see Características). Its syntax is:

guix package opciones

Primariamente, opciones especifica las operaciones a ser realizadas durante la transacción. Al completarse, un nuevo perfil es creado, pero las generaciones previas del perfil permanecen disponibles, en caso de que la usuaria quisiera volver atrás.

Por ejemplo, para borrar lua e instalar guile y guile-cairo en una única transacción:

guix package -r lua -i guile guile-cairo

Para su conveniencia, también se proporcionan los siguientes alias:

• guix search es un alias de guix package -s,
• guix install es un alias de guix package -i,
• guix remove es un alias de guix package -r,
• guix upgrade es un alias de guix package -u
• y guix show es un alias de guix package --show=.

Estos alias tienen menos capacidad expresiva que guix package y proporcionan menos opciones, por lo que en algunos casos es probable que desee usar guix package directamente.

guix package también proporciona una aproximación declarativa, donde la usuaria especifica el conjunto exacto de paquetes a poner disponibles y la pasa a través de la opción --manifest (see --manifest).

Para cada usuaria, un enlace simbólico al perfil predeterminado de la usuaria es creado en $HOME/.guix-profile. Este enlace simbólico siempre apunta a la generación actual del perfil predeterminado de la usuaria. Por lo tanto, las usuarias pueden añadir $HOME/.guix-profile/bin a su variable de entorno PATH, etcétera. Si no está usando el sistema Guix, considere la adición de las siguientes líneas en su ~/.bash_profile (see Bash Startup Files in The GNU Bash Reference Manual) de manera que los nuevos intérpretes que ejecute obtengan todas las definiciones correctas de las variables de entorno:

GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$GUIX_PROFILE/etc/profile"

En una configuración multiusuaria, los perfiles de usuaria se almacenan en un lugar registrado como una raíz del sistema de archivos, a la que apunta $HOME/.guix-profile (see Invocación de guix gc). Ese directorio normalmente es localstatedir/guix/profiles/per-user/usuaria, donde localstatedir es el valor pasado a configure como --localstatedir y usuaria es el nombre de usuaria. El directorio per-user se crea cuando se lanza guix-daemon, y el subdirectorio usuaria es creado por guix package.

Las opciones pueden ser las siguientes:

--install=paquete …

-i paquete …

Instala los paquetes especificados.

Each package may specify a simple package name, such as guile, optionally followed by an at-sign and version number, such as guile@3.0.7 or simply guile@3.0. In the latter case, the newest version prefixed by 3.0 is selected.

If no version number is specified, the newest available version will be selected. In addition, such a package specification may contain a colon, followed by the name of one of the outputs of the package, as in gcc:doc or binutils@2.22:lib (see Paquetes con múltiples salidas).

Packages with a corresponding name (and optionally version) are searched for among the GNU distribution modules (see Módulos de paquetes).

Alternatively, a package can directly specify a store file name such as /gnu/store/...-guile-3.0.7, as produced by, e.g., guix build.

A veces los paquetes tienen entradas propagadas: estas son las dependencias que se instalan automáticamente junto al paquete requerido (see propagated-inputs in package objects, para información sobre las entradas propagadas en las definiciones de paquete).

Un ejemplo es la biblioteca GNU MPC: sus archivos de cabecera C hacen referencia a los de la biblioteca GNU MPFR, que a su vez hacen referencia a los de la biblioteca GMP. Por tanto, cuando se instala MPC, las bibliotecas MPFR y GMP también se instalan en el perfil; borrar MPC también borra MPFR y GMP—a menos que también se hayan instalado explícitamente por la usuaria.

Por otra parte, los paquetes a veces dependen de la definición de variables de entorno para sus rutas de búsqueda (véase a continuación la explicación de --seach-paths). Cualquier definición de variable de entorno que falte o sea posiblemente incorrecta se informa aquí.

--install-from-expression=exp

-e exp

Instala el paquete al que exp evalúa.

exp must be a Scheme expression that evaluates to a <package> object. This option is notably useful to disambiguate between same-named variants of a package, with expressions such as (@ (gnu packages commencement) guile-final).

Fíjese que esta opción instala la primera salida del paquete especificado, lo cual puede ser insuficiente cuando se necesita una salida específica de un paquete con múltiples salidas.

--install-from-file=archivo

-f archivo

Instala el paquete que resulta de evaluar el código en archivo.

Como un ejemplo, archivo puede contener una definición como esta (see Definición de paquetes):

(use-modules (guix)
             (guix build-system gnu)
             (guix licenses))

(package
  (name "hello")
  (version "2.10")
  (source (origin
            (method url-fetch)
            (uri (string-append "mirror://gnu/hello/hello-" version
                                ".tar.gz"))
            (sha256
             (base32
              "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
  (build-system gnu-build-system)
  (synopsis "Hello, GNU world: An example GNU package")
  (description "Guess what GNU Hello prints!")
  (home-page "http://www.gnu.org/software/hello/")
  (license gpl3+))

Developers may find it useful to include such a guix.scm file in the root of their project source tree that can be used to test development snapshots and create reproducible development environments (see Invoking guix shell).

El archivo puede contener también una representación en JSON de una o más definiciones de paquetes. Ejecutar guix package -f en hello.json con el contenido mostrado a continuación provocará la instalación del paquete greeter tras la construcción de myhello:

[
  {
    "name": "myhello",
    "version": "2.10",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "tests?": false
    },
    "home-page": "https://www.gnu.org/software/hello/",
    "synopsis": "Hello, GNU world: An example GNU package",
    "description": "GNU Hello prints a greeting.",
    "license": "GPL-3.0+",
    "native-inputs": ["gettext"]
  },
  {
    "name": "greeter",
    "version": "1.0",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "test-target": "foo",
      "parallel-build?": false
    },
    "home-page": "https://example.com/",
    "synopsis": "Greeter using GNU Hello",
    "description": "This is a wrapper around GNU Hello.",
    "license": "GPL-3.0+",
    "inputs": ["myhello", "hello"]
  }
]

--remove=paquete …

-r paquete …

Borra los paquetes especificados.

Como en --install, cada paquete puede especificar un número de versión y/o un nombre de salida además del nombre del paquete. Por ejemplo, -r glibc:debug eliminaría la salida debug de glibc.

--upgrade[=regexp …] ¶

-u [regexp …]

Actualiza todos los paquetes instalados. Si se especifica una o más expresiones regular regexp, actualiza únicamente los paquetes instalados cuyo nombre es aceptado por regexp. Véase también la opción --do-not-upgrade más adelante.

Tenga en cuenta que esto actualiza los paquetes a la última versión encontrada en la distribución instalada actualmente. Para actualizar su distribución, debe ejecutar regularmente guix pull (see Invocación de guix pull).

Al actualizar, las transformaciones que se aplicaron originalmente al crear el perfil se aplican de nuevo de manera automática (see Opciones de transformación de paquetes). Por ejemplo, asumiendo que hubiese instalado Emacs a partir de la última revisión de su rama de desarrollo con:

guix install emacs-next --with-branch=emacs-next=master

La próxima vez que ejecute guix upgrade Guix obtendrá de nuevo la última revisión de la rama de desarrollo de Emacs y construirá emacs-next a partir de ese código.

Tenga en cuenta que las opciones de transformación, como por ejemplo --with-branch y --with-source, dependen de un estado externo; es su responsabilidad asegurarse de que funcionen de la manera esperada. También puede deshacer las transformaciones aplicadas a un paquete con la siguiente orden:

guix install paquete

--do-not-upgrade[=regexp …]

Cuando se usa junto a la opción --upgrade, no actualiza ningún paquete cuyo nombre sea aceptado por regexp. Por ejemplo, para actualizar todos los paquetes en el perfil actual excepto aquellos que contengan la cadena “emacs”:

$ guix package --upgrade . --do-not-upgrade emacs

--manifest=archivo ¶

-m archivo

Crea una nueva generación del perfil desde el objeto de manifiesto devuelto por el código Scheme en archivo. Esta opción puede repetirse varias veces, en cuyo caso los manifiestos se concatenan.

Esto le permite declarar los contenidos del perfil en vez de construirlo a través de una secuencia de --install y órdenes similares. La ventaja es que archivo puede ponerse bajo control de versiones, copiarse a máquinas diferentes para reproducir el mismo perfil, y demás.

archivo debe devolver un objeto manifest, que es básicamente una lista de paquetes:

(use-package-modules guile emacs)

(packages->manifest
 (list emacs
       guile-2.0
       ;; Usa una salida específica del paquete.
       (list guile-2.0 "debug")))

See Writing Manifests, for information on how to write a manifest. See --export-manifest, to learn how to obtain a manifest file from an existing profile.

--roll-back ¶

Vuelve a la generación previa del perfil—es decir, revierte la última transacción.

Cuando se combina con opciones como --install, la reversión atrás ocurre antes que cualquier acción.

Cuando se vuelve atrás en la primera generación que realmente contiene paquetes instalados, se hace que el perfil apunte a la generación cero, la cual no contiene ningún archivo a excepción de sus propios metadatos.

Después de haber vuelto atrás, instalar, borrar o actualizar paquetes sobreescribe las generaciones futuras previas. Por tanto, la historia de las generaciones en un perfil es siempre linear.

--switch-generation=patrón ¶

-S patrón

Cambia a una generación particular definida por el patrón.

patrón puede ser tanto un número de generación como un número prefijado con “+” o “-”. Esto último significa: mueve atrás/hacia delante el número especificado de generaciones. Por ejemplo, si quiere volver a la última generación antes de --roll-back, use --switch-generation=+1.

La diferencia entre --roll-back y --switch-generation=-1 es que --switch-generation no creará una generación cero, así que si la generación especificada no existe, la generación actual no se verá cambiada.

--search-paths[=tipo] ¶

Informa de variables de entorno, en sintaxis Bash, que pueden necesitarse para usar el conjunto de paquetes instalado. Estas variables de entorno se usan para especificar las rutas de búsqueda para archivos usadas por algunos de los paquetes.

For example, GCC needs the CPATH and LIBRARY_PATH environment variables to be defined so it can look for headers and libraries in the user’s profile (see Environment Variables in Using the GNU Compiler Collection (GCC)). If GCC and, say, the C library are installed in the profile, then --search-paths will suggest setting these variables to profile/include and profile/lib, respectively (see Search Paths, for info on search path specifications associated with packages.)

El caso de uso típico es para definir estas variables de entorno en el intérprete de consola:

$ eval $(guix package --search-paths)

tipo puede ser exact, prefix o suffix, lo que significa que las definiciones de variables de entorno devueltas serán respectivamente las configuraciones exactas, prefijos o sufijos del valor actual de dichas variables. Cuando se omite, el valor predeterminado de tipo es exact.

Esta opción puede usarse para calcular las rutas de búsqueda combinadas de varios perfiles. Considere este ejemplo:

$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths

La última orden informa sobre la variable GUILE_LOAD_PATH, aunque, tomada individualmente, ni foo ni bar hubieran llevado a esa recomendación.

--profile=perfil

-p perfil

Usa perfil en vez del perfil predeterminado de la usuaria.

perfil debe ser el nombre de un archivo que se creará tras completar las tareas. Concretamente, perfil sera simplemente un enlace simbólico (“symlink”) que apunta al verdadero perfil en el que se instalan los paquetes:

$ guix install hello -p ~/código/mi-perfil
…
$ ~/código/mi-perfil/bin/hello
¡Hola mundo!

Todo lo necesario para deshacerse del perfil es borrar dicho enlace simbólico y sus enlaces relacionados que apuntan a generaciones específicas:

$ rm ~/código/mi-perfil ~/código/mi-perfil-*-link

--list-profiles

Enumera los perfiles de la usuaria:

$ guix package --list-profiles
/home/carlos/.guix-profile
/home/carlos/código/mi-perfil
/home/carlos/código/perfil-desarrollo
/home/carlos/tmp/prueba

Cuando se ejecuta como root, enumera todos los perfiles de todas las usuarias.

--allow-collisions

Permite colisiones de paquetes en el nuevo perfil. ¡Úselo bajo su propio riesgo!

Por defecto, guix package informa como un error las colisiones en el perfil. Las colisiones ocurren cuando dos o más versiones diferentes o variantes de un paquete dado se han seleccionado para el perfil.

--bootstrap

Use el Guile usado para el lanzamiento para construir el perfil. Esta opción es util únicamente a las desarrolladoras de la distribución.

Además de estas acciones, guix package acepta las siguientes opciones para consultar el estado actual de un perfil, o la disponibilidad de paquetes:

--search=regexp

-s regexp

Enumera los paquetes disponibles cuyo nombre, sinopsis o descripción corresponde con regexp (sin tener en cuenta la capitalización), ordenados por relevancia. Imprime todos los metadatos de los paquetes coincidentes en formato recutils (see GNU recutils databases in GNU recutils manual).

Esto permite extraer campos específicos usando la orden recsel, por ejemplo:

$ guix package -s malloc | recsel -p name,version,relevance
name: jemalloc
version: 4.5.0
relevance: 6

name: glibc
version: 2.25
relevance: 1

name: libgc
version: 7.6.0
relevance: 1

De manera similar, para mostrar el nombre de todos los paquetes disponibles bajo los términos de la GNU LGPL versión 3:

$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
name: elfutils

name: gmp
…

También es posible refinar los resultados de búsqueda mediante el uso de varias opciones -s, o varios parámetros a guix search. Por ejemplo, la siguiente orden devuelve un lista de juegos de mesa¹² (esta vez mediante el uso del alias guix search:

$ guix search '\<board\>' game | recsel -p name
name: gnubg
…

Si omitimos -s game, también obtendríamos paquetes de software que tengan que ver con placas de circuitos impresos ("circuit board" en inglés); borrar los signos mayor y menor alrededor de board añadiría paquetes que tienen que ver con teclados (keyboard en inglés).

Y ahora para un ejemplo más elaborado. La siguiente orden busca bibliotecas criptográficas, descarta bibliotecas Haskell, Perl, Python y Ruby, e imprime el nombre y la sinopsis de los paquetes resultantes:

$ guix search crypto library | \
    recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis

See Selection Expressions in GNU recutils manual, para más información en expresiones de selección para recsel -e.

--show=paquete

Muestra los detalles del paquete, tomado de la lista disponible de paquetes, en formato recutils (see GNU recutils databases in GNU recutils manual).

$ guix package --show=guile | recsel -p name,version
name: guile
version: 3.0.5

name: guile
version: 3.0.2

name: guile
version: 2.2.7
…

También puede especificar el nombre completo de un paquete para únicamente obtener detalles sobre una versión específica (esta vez usando el alias guix show):

$ guix show guile@3.0.5 | recsel -p name,version
name: guile
version: 3.0.5

--list-installed[=regexp]

-I [regexp]

Enumera los paquetes actualmente instalados en el perfil especificado, con los últimos paquetes instalados mostrados al final. Cuando se especifica regexp, enumera únicamente los paquetes instalados cuyos nombres son aceptados por regexp.

Por cada paquete instalado, imprime los siguientes elementos, separados por tabuladores: el nombre del paquete, la cadena de versión, la parte del paquete que está instalada (por ejemplo, out para la salida predeterminada, include para sus cabeceras, etc.), y la ruta de este paquete en el almacén.

--list-available[=regexp]

-A [regexp]

Enumera los paquetes disponibles actualmente en la distribución para este sistema (see Distribución GNU). Cuando se especifica regexp, enumera únicamente paquetes disponibles cuyo nombre coincide con regexp.

Por cada paquete, imprime los siguientes elementos separados por tabuladores: su nombre, su cadena de versión, las partes del paquete (see Paquetes con múltiples salidas) y la dirección de las fuentes de su definición.

--list-generations[=patrón] ¶

-l [patrón]

Devuelve una lista de generaciones junto a sus fechas de creación; para cada generación, muestra los paquetes instalados, con los paquetes instalados más recientemente mostrados los últimos. Fíjese que la generación cero nunca se muestra.

Por cada paquete instalado, imprime los siguientes elementos, separados por tabuladores: el nombre de un paquete, su cadena de versión, la parte del paquete que está instalada (see Paquetes con múltiples salidas), y la ruta de este paquete en el almacén.

Cuando se usa patrón, la orden devuelve únicamente las generaciones que se ajustan al patrón. Entre los patrones adecuados se encuentran:

• Enteros y enteros separados por comas. Ambos patrones denotan números de generación. Por ejemplo, --list-generations=1 devuelve la primera.

  Y --list-generations=1,8,2 devuelve las tres generaciones en el orden especificado. No se permiten ni espacios ni una coma al final.

• Rangos. --list-generations=2..9 imprime las generaciones especificadas y todas las intermedias. Fíjese que el inicio de un rango debe ser menor a su fin.

  También es posible omitir el destino final. Por ejemplo, --list-generations=2.. devuelve todas las generaciones empezando por la segunda.

• Duraciones. Puede también obtener los últimos N días, semanas, o meses pasando un entero junto a la primera letra de la duración. Por ejemplo, --list-generations=20d enumera las generaciones que tienen hasta 20 días de antigüedad.

--delete-generations[=patrón]

-d [patrón]

Cuando se omite patrón, borra todas las generaciones excepto la actual.

Esta orden acepta los mismos patrones que --list-generations. Cuando se especifica un patrón, borra las generaciones coincidentes. Cuando el patrón especifica una duración, las generaciones más antiguas que la duración especificada son las borradas. Por ejemplo, --delete-generations=1m borra las generaciones de más de un mes de antigüedad.

Si la generación actual entra en el patrón, no es borrada. Tampoco la generación cero es borrada nunca.

Preste atención a que el borrado de generaciones previas impide la reversión a su estado. Consecuentemente esta orden debe ser usada con cuidado.

--export-manifest

Write to standard output a manifest suitable for --manifest corresponding to the chosen profile(s).

This option is meant to help you migrate from the “imperative” operating mode—running guix install, guix upgrade, etc.—to the declarative mode that --manifest offers.

Be aware that the resulting manifest approximates what your profile actually contains; for instance, depending on how your profile was created, it can refer to packages or package versions that are not exactly what you specified.

Keep in mind that a manifest is purely symbolic: it only contains package names and possibly versions, and their meaning varies over time. If you wish to “pin” channels to the revisions that were used to build the profile(s), see --export-channels below.

--export-channels

Write to standard output the list of channels used by the chosen profile(s), in a format suitable for guix pull --channels or guix time-machine --channels (see Canales).

Together with --export-manifest, this option provides information allowing you to replicate the current profile (see Replicación de Guix).

However, note that the output of this command approximates what was actually used to build this profile. In particular, a single profile might have been built from several different revisions of the same channel. In that case, --export-manifest chooses the last one and writes the list of other revisions in a comment. If you really need to pick packages from different channel revisions, you can use inferiors in your manifest to do so (see Inferiores).

Together with --export-manifest, this is a good starting point if you are willing to migrate from the “imperative” model to the fully declarative model consisting of a manifest file along with a channels file pinning the exact channel revision(s) you want.

Finally, since guix package may actually start build processes, it supports all the common build options (see Opciones comunes de construcción). It also supports package transformation options, such as --with-source, and preserves them across upgrades (see Opciones de transformación de paquetes).

5.3 Sustituciones

Guix permite despliegues transparentes de fuentes/binarios, lo que significa que puede tanto construir cosas localmente, como descargar elementos preconstruidos de un servidor, o ambas. Llamamos a esos elementos preconstruidos sustituciones—son sustituciones de los resultados de construcciones locales. En muchos casos, descargar una sustitución es mucho más rápido que construirla localmente.

Las sustituciones pueden ser cualquier cosa que resulte de una construcción de una derivación (see Derivaciones). Por supuesto, en el caso común, son paquetes binarios preconstruidos, pero los archivos de fuentes, por ejemplo, que también resultan de construcciones de derivaciones, pueden estar disponibles como sustituciones.

• Official Substitute Servers
• Autorización de servidores de sustituciones
• Obtención de sustiticiones desde otros servidores
• Verificación de sustituciones
• Configuración de la pasarela.
• Fallos en las sustituciones
• Sobre la confianza en binarios

# guix archive --authorize < prefix/share/guix/bordeaux.guix.gnu.org.pub
# guix archive --authorize < prefix/share/guix/ci.guix.gnu.org.pub

$ guix build emacs --dry-run
Se construirían las siguientes derivaciones:
   /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv
   /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv
   /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv
   /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv
…

$ guix build emacs --dry-run
Se descargarían 112.3 MB:
   /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3
   /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d
   /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16
   /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7
…

(operating-system
  ;; …
  (services
    ;; Se asume que se parte de '%desktop-services'. Debe sustituirse
    ;; por la lista de servicios que use en realidad.
    (modify-services %desktop-services
      (guix-service-type config =>
                        (guix-configuration
                          (inherit config)
                          (substitute-urls
                            (append (list "https://guix.example.org")
                                    %default-substitute-urls))
                          (authorized-keys
                            (append (list (local-file "./clave.pub"))
                                    %default-authorized-guix-keys)))))))

$ sudo guix system reconfigure /etc/config.scm
$ sudo herd restart guix-daemon

--substitute-urls="https://a.example.org https://b.example.org"

5.4 Paquetes con múltiples salidas

Habitualmente, los paquetes definidos en Guix tienen una salida única—es decir, el paquete de fuentes proporcionará exactamente un directorio en el almacén. Cuando se ejecuta guix install glibc, se instala la salida predeterminada del paquete GNU libc; la salida predeterminada se llama out, pero su nombre puede omitirse como se mostró en esta orden. En este caso particular, la salida predeterminada de glibc contiene todos archivos de cabecera C, bibliotecas dinámicas, bibliotecas estáticas, documentación Info y otros archivos auxiliares.

A veces es más apropiado separar varios tipos de archivos producidos por un paquete único de fuentes en salidas separadas. Por ejemplo, la biblioteca C GLib (usada por GTK+ y paquetes relacionados) instala más de 20 MiB de documentación de referencia como páginas HTML. Para ahorrar espacio para usuarias que no la necesiten, la documentación va a una salida separada, llamada doc. Para instalar la salida principal de GLib, que contiene todo menos la documentación, se debe ejecutar:

guix install glib

La orden que instala su documentación es:

guix install glib:doc

While the colon syntax works for command-line specification of package outputs, it will not work when using a package variable in Scheme code. For example, to add the documentation of glib to the globally installed packages of an operating-system (see Referencia de operating-system), a list of two items, the first one being the package variable and the second one the name of the output to select (a string), must be used instead:

(use-modules (gnu packages glib))
;; glib-with-documentation is the Guile symbol for the glib package
(operating-system
 ...
 (packages
  (append
   (list (list glib-with-documentation "doc"))
         %base-packages)))

Algunos paquetes instalan programas con diferentes “huellas de dependencias”. Por ejemplo, el paquete WordNet instala tanto herramientas de línea de órdenes como interfaces gráficas de usuaria (IGU). Las primeras dependen únicamente de la biblioteca de C, mientras que las últimas dependen en Tcl/Tk y las bibliotecas de X subyacentes. En este caso, dejamos las herramientas de línea de órdenes en la salida predeterminada, mientras que las IGU están en una salida separada. Esto permite a las usuarias que no necesitan una IGU ahorrar espacio. La orden guix size puede ayudar a exponer estas situaciones (see Invocación de guix size). guix graph también puede ser útil (see Invocación de guix graph).

Hay varios de estos paquetes con salida múltiple en la distribución GNU. Otros nombres de salida convencionales incluyen lib para bibliotecas y posiblemente archivos de cabecera, bin para programas independientes y debug para información de depuración (see Instalación de archivos de depuración). La salida de los paquetes se enumera en la tercera columna del resultado de guix package --list-available (see Invocación de guix package).

5.5 Invoking guix locate

There’s so much free software out there that sooner or later, you will need to search for packages. The guix search command that we’ve seen before (see Invocación de guix package) lets you search by keywords:

guix search video editor

Sometimes, you instead want to find which package provides a given file, and this is where guix locate comes in. Here is how you can find which package provides the ls command:

$ guix locate ls
coreutils@9.1       /gnu/store/…-coreutils-9.1/bin/ls

Of course the command works for any file, not just commands:

$ guix locate unistr.h
icu4c@71.1          /gnu/store/…/include/unicode/unistr.h
libunistring@1.0    /gnu/store/…/include/unistr.h

You may also specify glob patterns with wildcards. For example, here is how you would search for packages providing .service files:

$ guix locate -g '*.service'
man-db@2.11.1        …/lib/systemd/system/man-db.service
wpa-supplicant@2.10  …/system-services/fi.w1.wpa_supplicant1.service

The guix locate command relies on a database that maps file names to package names. By default, it automatically creates that database if it does not exist yet by traversing packages available locally, which can take a few minutes (depending on the size of your store and the speed of your storage device).

Nota: For now, guix locate builds its database based on purely local knowledge—meaning that you will not find packages that never reached your store. Eventually it will support downloading a pre-built database so you can potentially find more packages.

By default, guix locate first tries to look for a system-wide database, usually under /var/cache/guix/locate; if it does not exist or is too old, it falls back to the per-user database, by default under ~/.cache/guix/locate. On a multi-user system, administrators may want to periodically update the system-wide database so that all users can benefit from it, for instance by setting up package-database-service-type (see package-database-service-type).

La sintaxis general es:

guix locate [options…] file…

... where file is the name of a file to search for (specifically, the “base name” of the file: files whose parent directories are called file are not matched).

Las opciones disponibles son las siguientes:

--glob

-g

Interpret file… as glob patterns—patterns that may include wildcards, such as ‘*.scm’ to denote all files ending in ‘.scm’.

--stats

Display database statistics.

--update

-u

Update the file database.

By default, the database is automatically updated when it is too old.

--clear

Clear the database and re-populate it.

This option lets you start anew, ensuring old data is removed from the database, which also avoids having an endlessly growing database. By default guix locate automatically does that periodically, though infrequently.

--database=file

Use file as the database, creating it if necessary.

By default, guix locate picks the database under ~/.cache/guix or /var/cache/guix, whichever is the most recent one.

--method=method

-m method

Use method to select the set of packages to index. Possible values are:

manifests

This is the default method: it works by traversing profiles on the machine and recording packages it encounters—packages you or other users of the machine installed, directly or indirectly. It is fast but it can miss other packages available in the store but not referred to by any profile.

store

This is a slower but more exhaustive method: it checks among all the existing packages those that are available in the store and records them.

5.6 Invocación de guix gc

Los paquetes instalados, pero no usados, pueden ser recolectados. La orden guix gc permite a las usuarias ejecutar explícitamente el recolector de basura para reclamar espacio del directorio /gnu/store—¡borrar archivos o directorios manualmente puede dañar el almacén sin reparación posible!

El recolector de basura tiene un conjunto de raíces conocidas: cualquier archivo en /gnu/store alcanzable desde una raíz se considera vivo y no puede ser borrado; cualquier otro archivo se considera muerto y puede ser borrado. El conjunto de raíces del recolector de basura (“raíces del GC” para abreviar) incluye los perfiles predeterminados de las usuarias; por defecto los enlaces bajo /var/guix/gcroots representan dichas raíces. Por ejemplo, nuevas raíces del GC pueden añadirse con guix build --root (see Invocación de guix build). La orden guix gc --list-roots las enumera.

Antes de ejecutar guix gc --collect-garbage para liberar espacio, habitualmente es útil borrar generaciones antiguas de los perfiles de usuaria; de ese modo, las construcciones antiguas de paquetes a las que dichas generaciones hacen referencia puedan ser reclamadas. Esto se consigue ejecutando guix package --delete-generations (see Invocación de guix package).

Nuestra recomendación es ejecutar una recolección de basura periódicamente, o cuando tenga poco espacio en el disco. Por ejemplo, para garantizar que al menos 5 GB están disponibles en su disco, simplemente ejecute:

guix gc -F 5G

Es completamente seguro ejecutarla como un trabajo periódico no-interactivo (see Ejecución de tareas programadas, para la configuración de un trabajo de ese tipo). La ejecución de guix gc sin ningún parámetro recolectará tanta basura como se pueda, pero eso es no es normalmente conveniente: puede encontrarse teniendo que reconstruir o volviendo a bajar software que está “muerto” desde el punto de vista del recolector pero que es necesario para construir otras piezas de software—por ejemplo, la cadena de herramientas de compilación.

La orden guix gc tiene tres modos de operación: puede ser usada para recolectar archivos muertos (predeterminado), para borrar archivos específicos (la opción --delete), para mostrar información sobre la recolección de basura o para consultas más avanzadas. Las opciones de recolección de basura son las siguientes:

--collect-garbage[=min]

-C [min]

Recolecta basura—es decir, archivos no alcanzables de /gnu/store y subdirectorios. Esta operación es la predeterminada cuando no se especifican opciones.

Cuando se proporciona min, para una vez que min bytes han sido recolectados. min puede ser un número de bytes, o puede incluir una unidad como sufijo, como MiB para mebibytes y GB para gigabytes (see size specifications in GNU Coreutils).

Cuando se omite min, recolecta toda la basura.

--free-space=libre

-F libre

Recolecta basura hasta que haya espacio libre bajo /gnu/store, si es posible: libre denota espacio de almacenamiento, por ejemplo 500MiB, como se ha descrito previamente.

Cuando libre o más está ya disponible en /gnu/store, no hace nada y sale inmediatamente.

--delete-generations[=duración]

-d [duración]

Before starting the garbage collection process, delete all the generations older than duration, for all the user profiles and home environment generations; when run as root, this applies to all the profiles of all the users.

Por ejemplo, esta orden borra todas las generaciones de todos sus perfiles que tengan más de 2 meses de antigüedad (excepto generaciones que sean las actuales), y una vez hecho procede a liberar espacio hasta que al menos 10 GiB estén disponibles:

guix gc -d 2m -F 10G

--delete

-D

Intenta borrar todos los archivos del almacén y directorios especificados como parámetros. Esto falla si alguno de los archivos no están en el almacén, o todavía están vivos.

--list-failures

Enumera los elementos del almacén correspondientes a construcciones fallidas existentes en la caché.

Esto no muestra nada a menos que el daemon se haya ejecutado pasando --cache-failures (see --cache-failures).

--list-roots

Enumera las raíces del recolector de basura poseídas por la usuaria; cuando se ejecuta como root, enumera todas las raíces del recolector de basura.

--list-busy

Enumera los elementos del almacén que actualmente están siendo usados por procesos en ejecución. Estos elementos del almacén se consideran de manera efectiva raíces del recolector de basura: no pueden borrarse.

--clear-failures

Borra los elementos especificados del almacén de la caché de construcciones fallidas.

De nuevo, esta opción únicamente tiene sentido cuando el daemon se inicia con --cache-failures. De otro modo, no hace nada.

--list-dead

Muestra la lista de archivos y directorios muertos todavía presentes en el almacén—es decir, archivos y directorios que ya no se pueden alcanzar desde ninguna raíz.

--list-live

Muestra la lista de archivos y directorios del almacén vivos.

Además, las referencias entre los archivos del almacén pueden ser consultadas:

--references ¶

--referrers

Enumera las referencias (o, respectivamente, los referentes) de los archivos del almacén pasados como parámetros.

--requisites ¶

-R

Enumera los requisitos los archivos del almacén pasados como parámetros. Los requisitos incluyen los mismos archivos del almacén, sus referencias, las referencias de estas, recursivamente. En otras palabras, la lista devuelta es la clausura transitiva de los archivos del almacén.

See Invocación de guix size, para una herramienta que perfila el tamaño de la clausura de un elemento. See Invocación de guix graph, para una herramienta de visualización del grafo de referencias.

--derivers ¶

Devuelve la/s derivación/es que conducen a los elementos del almacén dados (see Derivaciones).

Por ejemplo, esta orden:

guix gc --derivers $(guix package -I ^emacs$ | cut -f4)

devuelve el/los archivo/s .drv que conducen al paquete emacs instalado en su perfil.

Fíjese que puede haber cero archivos .drv encontrados, por ejemplo porque estos archivos han sido recolectados. Puede haber más de un archivo .drv encontrado debido a derivaciones de salida fija.

Por último, las siguientes opciones le permiten comprobar la integridad del almacén y controlar el uso del disco.

--verify[=opciones] ¶

Verifica la integridad del almacén.

Por defecto, comprueba que todos los elementos del almacén marcados como válidos en la base de datos del daemon realmente existen en /gnu/store.

Cuando se proporcionan, opciones debe ser una lista separada por comas que contenga uno o más valores contents and repair.

Cuando se usa --verify=contents, el daemon calcula el hash del contenido de cada elemento del almacén y lo compara contra el hash de su base de datos. Las incongruencias se muestran como corrupciones de datos. Debido a que recorre todos los archivos del almacén, esta orden puede tomar mucho tiempo, especialmente en sistemas con una unidad de disco lenta.

El uso de --verify=repair o --verify=contents,repair hace que el daemon intente reparar elementos corruptos del almacén obteniendo sustituciones para dichos elementos (see Sustituciones). Debido a que la reparación no es atómica, y por tanto potencialmente peligrosa, está disponible únicamente a la administradora del sistema. Una alternativa ligera, cuando sabe exactamente qué elementos del almacén están corruptos, es guix build --repair (see Invocación de guix build).

--optimize ¶

Optimiza el almacén sustituyendo archivos idénticos por enlaces duros—esto es la deduplicación.

El daemon realiza la deduplicación después de cada construcción satisfactoria o importación de archivos, a menos que se haya lanzado con la opción --disable-deduplication (see --disable-deduplication). Por tanto, esta opción es útil principalmente cuando el daemon se estaba ejecutando con --disable-deduplication.

--vacuum-database ¶

Guix uses an sqlite database to keep track of the items in (see El almacén). Over time it is possible that the database may grow to a large size and become fragmented. As a result, one may wish to clear the freed space and join the partially used pages in the database left behind from removed packages or after running the garbage collector. Running sudo guix gc --vacuum-database will lock the database and VACUUM the store, defragmenting the database and purging freed pages, unlocking the database when it finishes.

5.7 Invocación de guix pull

Packages are installed or upgraded to the latest version available in the distribution currently available on your local machine. To update that distribution, along with the Guix tools, you must run guix pull: the command downloads the latest Guix source code and package descriptions, and deploys it. Source code is downloaded from a Git repository, by default the official GNU Guix repository, though this can be customized. guix pull ensures that the code it downloads is authentic by verifying that commits are signed by Guix developers.

Specifically, guix pull downloads code from the channels (see Canales) specified by one of the following, in this order:

1. la opción --channels;
2. the user’s ~/.config/guix/channels.scm file, unless -q is passed;
3. the system-wide /etc/guix/channels.scm file, unless -q is passed (on Guix System, this file can be declared in the operating system configuration, see channels field of guix-configuration);
4. los canales predeterminados en código especificados en la variable %default-channels.

Una vez completada, guix package usará paquetes y versiones de paquetes de esta copia recién obtenida de Guix. No solo eso, sino que todas las órdenes de Guix y los módulos Scheme también se tomarán de la última versión. Nuevas sub-órdenes guix incorporadas por la actualización también estarán disponibles.

Cualquier usuaria puede actualizar su copia de Guix usando guix pull, y el efecto está limitado a la usuaria que ejecute guix pull. Por ejemplo, cuando la usuaria root ejecuta guix pull, dicha acción no produce ningún efecto en la versión del Guix que la usuaria alicia ve, y viceversa.

El resultado de ejecutar guix pull es un perfil disponible bajo ~/.config/guix/current conteniendo el último Guix.

Las opciones --list-generations o -l enumeran las generaciones pasadas producidas por guix pull, junto a detalles de su procedencia:

$ guix pull -l
Generación 1	10 jun 2018 00:18:18
  guix 65956ad
    URL del repositorio: https://git.savannah.gnu.org/git/guix.git
    rama: origin/master
    revisión: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe

Generation 2	Jun 11 2018 11:02:49
  guix e0cc7f6
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: origin/master
    commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d

Generation 3	Jun 13 2018 23:31:07	(current)
  guix 844cc1c
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: origin/master
    commit: 844cc1c8f394f03b404c5bb3aee086922373490c

guix describe, para otras formas de describir el estado actual de Guix.

This ~/.config/guix/current profile works exactly like the profiles created by guix package (see Invocación de guix package). That is, you can list generations, roll back to the previous generation—i.e., the previous Guix—and so on:

$ guix pull --roll-back
se pasó de la generación 3 a la 2
$ guix pull --delete-generations=1
borrando /var/guix/profiles/per-user/carlos/current-guix-1-link

También puede usar guix package (see Invocación de guix package) para gestionar el perfil proporcionando su nombre de manera específica:

$ guix package -p ~/.config/guix/current --roll-back
se pasó de la generación 3 a la 2
$ guix package -p ~/.config/guix/current --delete-generations=1
borrando /var/guix/profiles/per-user/carlos/current-guix-1-link

La orden guix pull se invoca habitualmente sin parámetros, pero permite las siguientes opciones:

--url=url

--commit=revisión

--branch=rama

Download code for the guix channel from the specified url, at the given commit (a valid Git commit ID represented as a hexadecimal string or the name of a tag), or branch.

Estas opciones se proporcionan por conveniencia, pero también puede especificar su configuración en el archivo ~/.config/guix/channels.scm o usando la opción --channels (vea más adelante).

--channels=archivo

-C archivo

Lee la lista de canales de archivo en vez de ~/.config/guix/channels.scm o /etc/guix/channels.scm. archivo debe contener código Scheme que evalúe a una lista de objetos “channel”. See Canales, para más información.

--no-channel-files

-q

Inhibit loading of the user and system channel files, ~/.config/guix/channels.scm and /etc/guix/channels.scm.

--news

-N

Display news written by channel authors for their users for changes made since the previous generation (see Writing Channel News). When --details is passed, additionally display new and upgraded packages.

You can view that information for previous generations with guix pull -l.

--list-generations[=patrón]

-l [patrón]

Enumera todas las generaciones de ~/.config/guix/current o, si se proporciona un patrón, el subconjunto de generaciones que correspondan con el patrón. La sintaxis de patrón es la misma que guix package --list-generations (see Invocación de guix package).

By default, this prints information about the channels used in each revision as well as the corresponding news entries. If you pass --details, it will also print the list of packages added and upgraded in each generation compared to the previous one.

--details

Instruct --list-generations or --news to display more information about the differences between subsequent generations—see above.

--roll-back ¶

Vuelve a la generación previa de ~/.config/guix/current—es decir, deshace la última transacción.

--switch-generation=patrón ¶

-S patrón

Cambia a una generación particular definida por el patrón.

patrón puede ser tanto un número de generación como un número prefijado con “+” o “-”. Esto último significa: mueve atrás/hacia delante el número especificado de generaciones. Por ejemplo, si quiere volver a la última generación antes de --roll-back, use --switch-generation=+1.

--delete-generations[=patrón]

-d [patrón]

Cuando se omite patrón, borra todas las generaciones excepto la actual.

Esta orden acepta los mismos patrones que --list-generations. Cuando se especifica un patrón, borra las generaciones coincidentes. Cuando el patrón especifica una duración, las generaciones más antiguas que la duración especificada son las borradas. Por ejemplo, --delete-generations=1m borra las generaciones de más de un mes de antigüedad.

Si la generación actual entra en el patrón, no será borrada.

Preste atención a que el borrado de generaciones previas impide la reversión a su estado. Consecuentemente esta orden debe ser usada con cuidado.

Invocación de guix describe, para una forma de mostrar información sobre únicamente la generación actual.

--profile=perfil

-p perfil

Usa perfil en vez de ~/.config/guix/current.

--dry-run

-n

Muestra qué revisión/es del canal serían usadas y qué se construiría o sustituiría, sin efectuar ninguna acción real.

--allow-downgrades

Permite obtener revisiones de los canales más antiguas o no relacionadas con aquellas que se encuentran en uso actualmente.

De manera predeterminada guix pull proteje contra los llamados “ataques de versión anterior” en los que el repositorio Git de un canal se reinicia a una revisión anterior o no relacionada de sí mismo, provocando potencialmente la instalación de versiones más antiguas y con vulnerabilidades conocidas de paquetes de software.

Nota: Asegúrese de entender las implicaciones de seguridad antes de usar la opción --allow-downgrades.

--disable-authentication

Permite obtener código de un canal sin verificarlo.

De manera predeterminada, guix pull valida el código que descarga de los canales verificando que sus revisiones están firmadas por desarrolladoras autorizadas, y emite un error si no es el caso. Esta opción le indica que no debe realizar ninguna de esas verificaciones.

Nota: Asegúrese de entender las implicaciones de seguridad antes de usar la opción --disable-authentication.

--system=sistema

-s sistema

Intenta construir paquetes para sistema—por ejemplo, x86_64-linux—en vez del tipo de sistema de la máquina de construcción.

--bootstrap

Use el Guile usado para el lanzamiento para construir el último Guix. Esta opción es útil para las desarrolladoras de Guix únicamente.

El mecanismo de canales le permite instruir a guix pull de qué repositorio y rama obtener los datos, así como repositorios adicionales que contengan módulos de paquetes que deben ser desplegados. See Canales, para más información.

Además, guix pull acepta todas las opciones de construcción comunes (see Opciones comunes de construcción).

5.8 Invocación de guix time-machine

La orden guix time-machine proporciona acceso a otras revisiones de Guix, por ejemplo para instalar versiones antiguas de un paquete, o para reproducir una computación en un entorno idéntico. La revisión de Guix que se usará se define por el identificador de una revisión o por un archivo de descripción de canales creado con guix describe (see Invocación de guix describe).

Let’s assume that you want to travel to those days of November 2020 when version 1.2.0 of Guix was released and, once you’re there, run the guile of that time:

guix time-machine --commit=v1.2.0 -- \
  environment -C --ad-hoc guile -- guile

The command above fetches Guix 1.2.0 (and possibly other channels specified by your channels.scm configuration files—see below) and runs its guix environment command to spawn an environment in a container running guile (guix environment has since been subsumed by guix shell; see Invoking guix shell). It’s like driving a DeLorean¹³! The first guix time-machine invocation can be expensive: it may have to download or even build a large number of packages; the result is cached though and subsequent commands targeting the same commit are almost instantaneous.

As for guix pull, in the absence of any options, time-machine fetches the latest commits of the channels specified in ~/.config/guix/channels.scm, /etc/guix/channels.scm, or the default channels; the -q option lets you ignore these configuration files. The command:

guix time-machine -q -- build hello

will thus build the package hello as defined in the main branch of Guix, without any additional channel, which is in general a newer revision of Guix than you have installed. Time travel works in both directions!

Nota: The history of Guix is immutable and guix time-machine provides the exact same software as they are in a specific Guix revision. Naturally, no security fixes are provided for old versions of Guix or its channels. A careless use of guix time-machine opens the door to security vulnerabilities. See --allow-downgrades.

guix time-machine raises an error when attempting to travel to commits older than “v0.16.0” (commit ‘4a0b87f0’), dated Dec. 2018. This is one of the oldest commits supporting the channel mechanism that makes “time travel” possible.

Nota: Although it should technically be possible to travel to such an old commit, the ease to do so will largely depend on the availability of binary substitutes. When traveling to a distant past, some packages may not easily build from source anymore. One such example are old versions of OpenSSL whose tests would fail after a certain date. This particular problem can be worked around by running a virtual build machine with its clock set to the right time (see Virtual Build Machines).

La sintaxis general es:

guix time-machine opciones… -- orden param…

donde orden and param… se proporcionan sin modificar a la orden guix de la revisión especificada. Las opciones que definen esta revisión son las mismas que se usan con guix pull (see Invocación de guix pull):

--url=url

--commit=revisión

--branch=rama

Use the guix channel from the specified url, at the given commit (a valid Git commit ID represented as a hexadecimal string or the name of a tag), or branch.

--channels=archivo

-C archivo

Lee la lista de canales de archivo. archivo debe contener código Scheme que evalúe a una lista de objetos “channel”. See Canales, para más información.

--no-channel-files

-q

Inhibit loading of the user and system channel files, ~/.config/guix/channels.scm and /etc/guix/channels.scm.

Thus, guix time-machine -q is equivalent to the following Bash command, using the “process substitution” syntax (see Process Substitution in The GNU Bash Reference Manual):

guix time-machine -C <(echo %default-channels) …

Tenga en cuenta que guix time-machine puede desencadenar construcciones de canales y sus dependencias, y que pueden controlarse mediante las opciones de construcción estándar (see Opciones comunes de construcción).

If guix time-machine is executed without any command, it prints the file name of the profile that would be used to execute the command. This is sometimes useful if you need to get store file name of the profile—e.g., when you want to guix copy it.

5.9 Inferiores

Nota: La funcionalidad descrita aquí es una “versión de evaluación tecnológica” en la versión 2a6d964. Como tal, la interfaz está sujeta a cambios.

A veces necesita mezclar paquetes de revisiones de la revisión de Guix que está ejecutando actualmente con paquetes disponibles en una revisión diferente. Los inferiores de Guix le permiten conseguirlo componiendo diferentes revisiones de Guix de modo arbitrario.

Técnicamente, un “inferior” es esencialmente un proceso Guix separado conectado con su Guix principal a través de una sesión interactiva (see Invocación de guix repl). El módulo (guix inferior) le permite crear inferiores y comunicarse con ellos. También proporciona una interfaz de alto nivel para buscar y manipular los paquetes que un inferior proporciona—paquetes de inferiores.

When combined with channels (see Canales), inferiors provide a simple way to interact with a separate revision of Guix. For example, let’s assume you want to install in your profile the current guile package, along with the guile-json as it existed in an older revision of Guix—perhaps because the newer guile-json has an incompatible API and you want to run your code against the old API. To do that, you could write a manifest for use by guix package --manifest (see Writing Manifests); in that manifest, you would create an inferior for that old Guix revision you care about, and you would look up the guile-json package in the inferior:

(use-modules (guix inferior) (guix channels)
             (srfi srfi-1))   ;para 'first'

(define channels
  ;; Esta es la revisión antigua de donde queremos
  ;; extraer guile-json.
  (list (channel
         (name 'guix)
         (url "https://git.savannah.gnu.org/git/guix.git")
         (commit
          "65956ad3526ba09e1f7a40722c96c6ef7c0936fe"))))

(define inferior
  ;; Un inferior que representa la revisión previa.
  (inferior-for-channels channels))

;; Ahora crea un manifiesto con el paquete "guile" actual
;; y el antiguo paquete "guile-json".
(packages->manifest
 (list (first (lookup-inferior-packages inferior "guile-json"))
       (specification->package "guile")))

En su primera ejecución, guix package --manifest puede tener que construir el canal que especificó antes de crear el inferior; las siguientes ejecuciones serán mucho más rápidas porque la revisión de Guix estará en la caché.

El módulo (guix inferior) proporciona los siguientes procedimientos para abrir un inferior:

Procedimiento: inferior-for-channels canales [#:cache-directory] [#:ttl]

Devuelve un inferior para canales, una lista de canales. Usa la caché en cache-directory, donde las entradas pueden ser reclamadas después de ttl segundos. Este procedimiento abre una nueva conexión al daemon de construcción.

Como efecto secundario, este procedimiento puede construir o sustituir binarios para canales, lo cual puede tomar cierto tiempo.

Procedimiento: open-inferior directorio [#:command "bin/guix"]

Abre el Guix inferior en directorio, ejecutando directorio/command repl o su equivalente. Devuelve #f si el inferior no pudo ser ejecutado.

Los procedimientos enumerados a continuación le permiten obtener y manipular paquetes de inferiores.

Procedimiento: inferior-packages inferior

Devuelve la lista de paquetes conocida por inferior.

Procedimiento: lookup-inferior-packages inferior nombre [versión]

Devuelve la lista ordenada de paquetes del inferior que corresponden con nombre en inferior, con los números de versión más altos primero. Si versión tiene un valor verdadero, devuelve únicamente paquetes con un número de versión cuyo prefijo es versión.

Procedimiento: inferior-package? obj

Devuelve verdadero si obj es un paquete inferior.

Procedimiento: inferior-package-name paquete

Procedimiento: inferior-package-version paquete

Procedimiento: inferior-package-synopsis paquete

Procedimiento: inferior-package-description paquete

Procedimiento: inferior-package-home-page paquete

Procedimiento: inferior-package-location paquete

Procedimiento: inferior-package-inputs paquete

Procedimiento: inferior-package-native-inputs paquete

Procedimiento: inferior-package-propagated-inputs paquete

Procedimiento: inferior-package-transitive-propagated-inputs paquete

Procedimiento: inferior-package-native-search-paths paquete

Procedimiento: inferior-package-transitive-native-search-paths paquete

Procedimiento: inferior-package-search-paths paquete

Estos procedimientos son la contraparte de los accesos a los registros de paquete (see Referencia de package). La mayor parte funcionan interrogando al inferior del que paquete viene, por lo que el inferior debe estar vivo cuando llama a dichos procedimientos.

Inferior packages can be used transparently like any other package or file-like object in G-expressions (see Expresiones-G). They are also transparently handled by the packages->manifest procedure, which is commonly used in manifests (see the --manifest option of guix package). Thus you can insert an inferior package pretty much anywhere you would insert a regular package: in manifests, in the packages field of your operating-system declaration, and so on.

5.10 Invocación de guix describe

A menudo desea responder a preguntas como: “¿Qué revisión de Guix estoy usando?” o “¿Qué canales estoy usando?” Esto es una información muy útil en muchas situaciones: si quiere replicar un entorno en una máquina diferente o cuenta de usuaria, si desea informar de un error o determinar qué cambio en los canales que usa lo causó, o si quiere almacenar el estado de su sistema por razones de reproducibilidad. La orden guix describe responde a estas preguntas.

Cuando se ejecuta desde un guix bajado con guix pull, guix describe muestra el/los canal/es desde el/los que se construyó, incluyendo la URL de su repositorio y los IDs de las revisiones (see Canales):

$ guix describe
Generation 10	Sep 03 2018 17:32:44	(current)
  guix e0fa68c
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: e0fa68c7718fffd33d81af415279d6ddb518f727

Si está familiarizado con el sistema de control de versiones Git, esto es similar a git describe; la salida también es similar a la de guix pull --list-generations, pero limitada a la generación actual (see the --list-generations option). Debido a que el ID de revisión Git mostrado antes refiere sin ambigüedades al estado de Guix, esta información es todo lo necesario para describir la revisión de Guix que usa, y también para replicarla.

Para facilitar la replicación de Guix, también se le puede solicitar a guix describe devolver una lista de canales en vez de la descripción legible por humanos mostrada antes:

$ guix describe -f channels
(list (channel
        (name 'guix)
        (url "https://git.savannah.gnu.org/git/guix.git")
        (commit
          "e0fa68c7718fffd33d81af415279d6ddb518f727")
        (introduction
          (make-channel-introduction
            "9edb3f66fd807b096b48283debdcddccfea34bad"
            (openpgp-fingerprint
              "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))))

Puede almacenar esto en un archivo y se lo puede proporcionar a guix pull -C en otra máquina o en un momento futuro, lo que instanciará esta revisión exacta de Guix (see the -C option). De aquí en adelante, ya que puede desplegar la misma revisión de Guix, puede también replicar un entorno completo de software. Nosotras humildemente consideramos que esto es impresionante, ¡y esperamos que le guste a usted también!

Los detalles de las opciones aceptadas por guix describe son las siguientes:

--format=formato

-f formato

Produce salida en el formato especificado, uno de:

human

produce salida legible por humanos;

channels

produce una lista de especificaciones de canales que puede ser pasada a guix pull -C o instalada como ~/.config/guix/channels.scm (see Invocación de guix pull);

channels-sans-intro

como channels, pero se omite el campo introduction; se puede usar para producir una especificación de canal adecuada para la versión 1.1.0 de Guix y versiones anteriores—el campo introduction está relacionado con la verificación de canales (see Verificación de canales) y no está implementado en dichas versiones;

json ¶

produce una lista de especificaciones de canales en formato JSON;

recutils

produce una lista de especificaciones de canales en formato Recutils.

--list-formats

Muestra los formatos disponibles para la opción --format.

--profile=perfil

-p perfil

Muestra información acerca del perfil.

5.11 Invocación de guix archive

La orden guix archive permite a las usuarias exportar archivos del almacén en un único archivador, e importarlos posteriormente en una máquina que ejecute Guix. En particular, permite que los archivos del almacén sean transferidos de una máquina al almacén de otra máquina.

Nota: Si está buscando una forma de producir archivos en un formato adecuado para herramientas distintas a Guix, see Invocación de guix pack.

Para exportar archivos del almacén como un archivo por la salida estándar, ejecute:

guix archive --export opciones especificaciones...

especificaciones deben ser o bien nombres de archivos del almacén o especificaciones de paquetes, como las de guix package (see Invocación de guix package). Por ejemplo, la siguiente orden crea un archivo que contiene la salida gui del paquete git y la salida principal de emacs:

guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar

Si los paquetes especificados no están todavía construidos, guix archive los construye automáticamente. El proceso de construcción puede controlarse mediante las opciones de construcción comunes (see Opciones comunes de construcción).

Para transferir el paquete emacs a una máquina conectada por SSH, se ejecutaría:

guix archive --export -r emacs | ssh otra-maquina guix archive --import

De manera similar, un perfil de usuaria completo puede transferirse de una máquina a otra de esta manera:

guix archive --export -r $(readlink -f ~/.guix-profile) | \
  ssh otra-maquina guix archive --import

No obstante, fíjese que, en ambos ejemplos, todo emacs y el perfil como también todas sus dependencias son transferidas (debido a la -r), independiente de lo que estuviese ya disponible en el almacén de la máquina objetivo. La opción --missing puede ayudar a esclarecer qué elementos faltan en el almacén objetivo. La orden guix copy simplifica y optimiza este proceso completo, así que probablemente es lo que debería usar en este caso (see Invocación de guix copy).

Cada elemento del almacén se escribe en formato de archivo normalizado o nar (descrito a continuación), y la salida de guix archive --export (y entrada de guix archive --import) es un empaquetado nar.

El formato “nar” es comparable a ‘tar’ en el espíritu, pero con diferencias que lo hacen más apropiado para nuestro propósito. Primero, en vez de almacenar todos los metadatos Unix de cada archivo, el formato nar solo menciona el tipo de archivo (normal, directorio o enlace simbólico); los permisos Unix y el par propietario/grupo se descartan. En segundo lugar, el orden en el cual las entradas de directorios se almacenan siempre siguen el orden de los nombres de archivos de acuerdo a la ordenación de cadenas en la localización C. Esto hace la producción del archivo completamente determinista.

El formato del empaquetado nar es esencialmente una concatenación de cero o más nar junto a metadatos para cada elemento del almacén que contiene: su nombre de archivo, referencias, derivación correspondiente y firma digital.

Durante la exportación, el daemon firma digitalmente los contenidos del archivo, y la firma digital se adjunta. Durante la importación, el daemon verifica la firma y rechaza la importación en caso de una firma inválida o si la clave firmante no está autorizada.

Las opciones principales son:

--export

Exporta los archivos del almacén o paquetes (véase más adelante). Escribe el archivo resultante a la salida estándar.

Las dependencias no están incluidas en la salida, a menos que se use --recursive.

-r

--recursive

Cuando se combina con --export, instruye a guix archive para incluir las dependencias de los elementos dados en el archivo. Por tanto, el archivo resultante está auto-contenido: contiene la clausura de los elementos exportados del almacén.

--import

Lee un archivo de la entrada estándar, e importa los archivos enumerados allí en el almacén. La operación se aborta si el archivo tiene una firma digital no válida, o si está firmado por una clave pública que no está entre las autorizadas (vea --authorize más adelante).

--missing

Lee una lista de nombres de archivos del almacén de la entrada estándar, uno por línea, y escribe en la salida estándar el subconjunto de estos archivos que faltan en el almacén.

--generate-key[=parámetros] ¶

Genera un nuevo par de claves para el daemon. Esto es un prerrequisito antes de que los archivos puedan ser exportados con --export. Esta operación es habitualmente instantánea pero puede tomar tiempo si la piscina de entropía necesita tiene que rellenarse. En el sistema Guix guix-service-type se encarga de generar este par de claves en el primer arranque.

El par de claves generado se almacena típicamente bajo /etc/guix, en signing-key.pub (clave pública) y signing-key.sec (clave privada, que se debe mantener secreta). Cuando parámetros se omite, se genera una clave ECDSA usando la curva Ed25519, o, en versiones de Libgcrypt previas a la 1.6.0, es una clave RSA de 4096 bits. De manera alternativa, los parámetros pueden especificar parámetros genkey adecuados para Libgcrypt (see gcry_pk_genkey in The Libgcrypt Reference Manual).

--authorize ¶

Autoriza importaciones firmadas con la clave pública pasada por la entrada estándar. La clave pública debe estar en el “formato avanzado de expresiones-s”—es decir, el mismo formato que el archivo signing-key.pub.

La lista de claves autorizadas se mantiene en el archivo editable por personas /etc/guix/acl. El archivo contiene “expresiones-s en formato avanzado” y está estructurado como una lista de control de acceso en el formato Infraestructura Simple de Clave Pública (SPKI).

--extract=directorio

-x directorio

Lee un único elemento del archivo como es ofrecido por los servidores de sustituciones (see Sustituciones) y lo extrae a directorio. Esta es una operación de bajo nivel necesitada únicamente para casos muy concretos; véase a continuación.

For example, the following command extracts the substitute for Emacs served by bordeaux.guix.gnu.org to /tmp/emacs:

$ wget -O - \
  https://bordeaux.guix.gnu.org/nar/gzip/…-emacs-24.5 \
  | gunzip | guix archive -x /tmp/emacs

Los archivos de un único elemento son diferentes de los archivos de múltiples elementos producidos por guix archive --export; contienen un único elemento del almacén, y no embeben una firma. Por tanto esta operación no verifica la firma y su salida debe considerarse insegura.

El propósito primario de esta operación es facilitar la inspección de los contenidos de un archivo que provenga probablemente de servidores de sustituciones en los que no se confía (see Invocación de guix challenge).

--list

-t

Lee un único elemento del archivo como es ofrecido por los servidores de sustituciones (see Sustituciones) e imprime la lista de archivos que contiene, como en este ejemplo:

$ wget -O - \
  https://bordeaux.guix.gnu.org/nar/lzip/…-emacs-26.3 \
  | lzip -d | guix archive -t

6.1 Especificación de canales adicionales

You can specify additional channels to pull from. To use a channel, write ~/.config/guix/channels.scm to instruct guix pull to pull from it in addition to the default Guix channel(s):

;; Añade variaciones de paquetes sobre los que proporciona Guix.
(cons (channel
        (name 'paquetes-personalizados)
        (url "https://example.org/paquetes-personalizados.git"))
      %default-channels)

Fíjese que el fragmento previo es (¡como siempre!) código Scheme; usamos cons para añadir un canal a la lista de canales a la que la variable %default-channels hace referencia (see cons and lists in GNU Guile Reference Manual). Con el archivo en este lugar, guix pull no solo construye Guix sino también los módulos de paquetes de su propio repositorio. El resultado en ~/.config/guix/current es la unión de Guix con sus propios módulos de paquetes:

$ guix describe
Generation 19	Aug 27 2018 16:20:48
  guix d894ab8
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
  variant-packages dd3df5e
    repository URL: https://example.org/variant-packages.git
    branch: master
    commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb

The output of guix describe above shows that we’re now running Generation 19 and that it includes both Guix and packages from the variant-packages channel (see Invocación de guix describe).

6.2 Uso de un canal de Guix personalizado

El canal llamado guix especifica de dónde debe descargarse el mismo Guix—sus herramientas de línea de órdenes y su colección de paquetes—. Por ejemplo, suponga que quiere actualizar de otra copia del repositorio Guix en example.org, y específicamente la rama super-hacks, para ello puede escribir en ~/.config/guix/channels.scm esta especificación:

;; Le dice a 'guix pull' que use mi propio repositorio.
(list (channel
        (name 'guix)
        (url "https://example.org/otro-guix.git")
        (branch "super-hacks")))

From there on, guix pull will fetch code from the super-hacks branch of the repository at example.org. The authentication concern is addressed below (see Verificación de canales).

Note that you can specify a local directory on the url field above if the channel that you intend to use resides on a local file system. However, in this case guix checks said directory for ownership before any further processing. This means that if the user is not the directory owner, but wants to use it as their default, they will then need to set it as a safe directory in their global git configuration file. Otherwise, guix will refuse to even read it. Supposing your system-wide local directory is at /src/guix.git, you would then create a git configuration file at ~/.gitconfig with the following contents:

[safe]
        directory = /src/guix.git

This also applies to the root user unless when called with sudo by the directory owner.

6.3 Replicación de Guix

The guix describe command shows precisely which commits were used to build the instance of Guix we’re using (see Invocación de guix describe). We can replicate this instance on another machine or at a different point in time by providing a channel specification “pinned” to these commits that looks like this:

;; Despliega unas revisiones específicas de mis canales de interés.
(list (channel
       (name 'guix)
       (url "https://git.savannah.gnu.org/git/guix.git")
       (commit "d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300"))
      (channel
       (name 'paquetes-personalizados)
       (url "https://example.org/paquetes-personalizados.git")
       (branch "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))

To obtain this pinned channel specification, the easiest way is to run guix describe and to save its output in the channels format in a file, like so:

guix describe -f channels > channels.scm

The resulting channels.scm file can be passed to the -C option of guix pull (see Invocación de guix pull) or guix time-machine (see Invocación de guix time-machine), as in this example:

guix time-machine -C channels.scm -- shell python -- python3

Given the channels.scm file, the command above will always fetch the exact same Guix instance, then use that instance to run the exact same Python (see Invoking guix shell). On any machine, at any time, it ends up running the exact same binaries, bit for bit.

Pinned channels address a problem similar to “lock files” as implemented by some deployment tools—they let you pin and reproduce a set of packages. In the case of Guix though, you are effectively pinning the entire package set as defined at the given channel commits; in fact, you are pinning all of Guix, including its core modules and command-line tools. You’re also getting strong guarantees that you are, indeed, obtaining the exact same software.

Esto le proporciona superpoderes, lo que le permite seguir la pista de la procedencia de los artefactos binarios con un grano muy fino, y reproducir entornos de software a su voluntad—un tipo de capacidad de “meta-reproducibilidad”, si lo desea. See Inferiores, para otro modo de tomar ventaja de estos superpoderes.

6.4 Customizing the System-Wide Guix

If you’re running Guix System or building system images with it, maybe you will want to customize the system-wide guix it provides—specifically, /run/current-system/profile/bin/guix. For example, you might want to provide additional channels or to pin its revision.

This can be done using the guix-for-channels procedure, which returns a package for the given channels, and using it as part of your operating system configuration, as in this example:

(use-modules (gnu packages package-management)
             (guix channels))

(define my-channels
  ;; Channels that should be available to
  ;; /run/current-system/profile/bin/guix.
  (append
   (list (channel
          (name 'guix-science)
          (url "https://github.com/guix-science/guix-science")
          (branch "master")))
   %default-channels))

(operating-system
  ;; …
  (services
    ;; Change the package used by 'guix-service-type'.
    (modify-services %base-services
      (guix-service-type
       config => (guix-configuration
                  (inherit config)
                  (channels my-channels)
                  (guix (guix-for-channels my-channels)))))))

The resulting operating system will have both the guix and the guix-science channels visible by default. The channels field of guix-configuration above further ensures that /etc/guix/channels.scm, which is used by guix pull, specifies the same set of channels (see channels field of guix-configuration).

The (gnu packages package-management) module exports the guix-for-channels procedure, described below.

Procedure: guix-for-channels channels

Return a package corresponding to channels.

The result is a “regular” package, which can be used in guix-configuration as shown above or in any other place that expects a package.

6.5 Verificación de canales

Las órdenes guix pull y guix time-machine verifican el código obtenido de los canales: se aseguran de que cada commit que se obtenga se encuentre firmado por una desarrolladora autorizada. El objetivo es proteger de modificaciones no-autorizadas al canal que podrían provocar que las usuarias ejecuten código pernicioso.

Como usuaria, debe proporcionar una presentación del canal en su archivo de canales de modo que Guix sepa como verificar su primera revision. La especificación de una canal, incluyendo su introducción, es más o menos así:

(channel
  (name 'un-canal)
  (url "https://example.org/un-canal.git")
  (introduction
   (make-channel-introduction
    "6f0d8cc0d88abb59c324b2990bfee2876016bb86"
    (openpgp-fingerprint
     "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))

La especificación previa muestra el nombre y la URL del canal. La llamada a make-channel-introduction especifica que la identificación de este canal empieza en la revisión 6f0d8cc…, que está firmada por la clave de OpenPGP que tiene la huella CABB A931….

En el canal principal, llamado guix, obtiene esta información de manera automática desde su instalación de Guix. Para otros canales, incluya la presentación del canal proporcionada por sus autoras en su archivo channels.scm. Asegúrese de obtener la presentación del canal desde una fuente confiable ya que es la raíz de su confianza.

Si tiene curiosidad sobre los mecanismos de identificación y verificación, ¡siga leyendo!

6.6 Channels with Substitutes

When running guix pull, Guix will first compile the definitions of every available package. This is an expensive operation for which substitutes (see Sustituciones) may be available. The following snippet in channels.scm will ensure that guix pull uses the latest commit with available substitutes for the package definitions: this is done by querying the continuous integration server at https://ci.guix.gnu.org.

(use-modules (guix ci))

(list (channel-with-substitutes-available
       %default-guix-channel
       "https://ci.guix.gnu.org"))

Note that this does not mean that all the packages that you will install after running guix pull will have available substitutes. It only ensures that guix pull will not try to compile package definitions. This is particularly useful when using machines with limited resources.

6.7 Creación de un canal

Let’s say you have a bunch of custom package variants or personal packages that you think would make little sense to contribute to the Guix project, but would like to have these packages transparently available to you at the command line. By creating a channel, you can use and publish such a package collection. This involves the following steps:

1. A channel lives in a Git repository so the first step, when creating a channel, is to create its repository:

   mkdir my-channel
   cd my-channel
   git init
   

2. The next step is to create files containing package modules (see Módulos de paquetes), each of which will contain one or more package definitions (see Definición de paquetes). A channel can provide things other than packages, such as build systems or services; we’re using packages as it’s the most common use case.

   For example, Alice might want to provide a module called (alice packages greetings) that will provide her favorite “hello world” implementations. To do that Alice will create a directory corresponding to that module name.

   mkdir -p alice/packages
   $EDITOR alice/packages/greetings.scm
   git add alice/packages/greetings.scm
   

   You can name your package modules however you like; the main constraint to keep in mind is to avoid name clashes with other package collections, which is why our hypothetical Alice wisely chose the (alice packages …) name space.

   Note that you can also place modules in a sub-directory of the repository; see Módulos de paquetes en un subdirectorio, for more info on that.

3. With this first module in place, the next step is to test the packages it provides. This can be done with guix build, which needs to be told to look for modules in the Git checkout. For example, assuming (alice packages greetings) provides a package called hi-from-alice, Alice will run this command from the Git checkout:

   guix build -L. hi-from-alice
   

   ... where -L. adds the current directory to Guile’s load path (see Load Paths in GNU Guile Reference Manual).

4. It might take Alice a few iterations to obtain satisfying package definitions. Eventually Alice will commit this file:

   git commit
   

   Como autora de un canal, considere adjuntar el material para la identificación a su canal de modo que las usuarias puedan verificarlo. See Verificación de canales, y Especificación de autorizaciones del canal, para obtener información sobre cómo hacerlo.

5. To use Alice’s channel, anyone can now add it to their channel file (see Especificación de canales adicionales) and run guix pull (see Invocación de guix pull):

   $EDITOR ~/.config/guix/channels.scm
   guix pull
   

   Guix will now behave as if the root directory of that channel’s Git repository had been permanently added to the Guile load path. In this example, (alice packages greetings) will automatically be found by the guix command.

Voilà!

Aviso: Before you publish your channel, we would like to share a few words of caution:

• Antes de publicar un canal, por favor considere contribuir sus definiciones de paquete al propio Guix (see Contribuir). Guix como proyecto es abierto a software libre de todo tipo, y los paquetes en el propio Guix están disponibles para todas las usuarias de Guix y se benefician del proceso de gestión de calidad del proyecto.
• Package modules and package definitions are Scheme code that uses various programming interfaces (APIs). We, Guix developers, never change APIs gratuitously, but we do not commit to freezing APIs either. When you maintain package definitions outside Guix, we consider that the compatibility burden is on you.
• Corolario: si está usando un canal externo y el canal se rompe, por favor informe del problema a las autoras del canal, no al proyecto Guix.

¡Ha quedado advertida! Habiendo dicho esto, creemos que los canales externos son una forma práctica de ejercitar su libertad para aumentar la colección de paquetes de Guix y compartir su mejoras, que son pilares básicos del software libre. Por favor, envíenos un correo a guix-devel@gnu.org si quiere hablar sobre esto.

6.8 Módulos de paquetes en un subdirectorio

Como autora de un canal, es posible que desee mantener los módulos de su canal en un subdirectorio. Si sus módulos se encuentran en el subdirectorio guix, debe añadir un archivo .guix-channel de metadatos que contenga:

(channel
  (version 0)
  (directory "guix"))

The modules must be underneath the specified directory, as the directory changes Guile’s load-path. For example, if .guix-channel has (directory "base"), then a module defined as (define-module (gnu packages fun)) must be located at base/gnu/packages/fun.scm.

Doing this allows for only parts of a repository to be used as a channel, as Guix expects valid Guile modules when pulling. For instance, guix deploy machine configuration files are not valid Guile modules, and treating them as such would make guix pull fail.

6.9 Declaración de dependencias de canales

Las autoras de canales pueden decidir aumentar una colección de paquetes proporcionada por otros canales. Pueden declarar su canal como dependiente de otros canales en el archivo de metadatos .guix-channel, que debe encontrarse en la raíz del repositorio del canal.

Este archivo de metadatos debe contener una expresión-S simple como esta:

(channel
 (version 0)
 (dependencies
  (channel
   (name some-collection)
   (url "https://example.org/first-collection.git")

   ;; The 'introduction' bit below is optional: you would
   ;; provide it for dependencies that can be authenticated.
   (introduction
    (channel-introduction
      (version 0)
      (commit "a8883b58dc82e167c96506cf05095f37c2c2c6cd")
      (signer "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))
  (channel
   (name some-other-collection)
   (url "https://example.org/second-collection.git")
   (branch "testing"))))

En el ejemplo previo, este canal se declara como dependiente de otros dos canales, que se obtendrán de manera automática. Los módulos proporcionados por el canal se compilarán en un entorno donde los módulos de todos estos canales declarados estén disponibles.

De cara a la confianza proporcionada y el esfuerzo que supondrá su mantenimiento, debería evitar depender de canales que no controle, y debería intentar minimizar el número de dependencias.

6.10 Especificación de autorizaciones del canal

Como hemos visto previamente, Guix se asegura de que el código fuente que obtiene de los canales proviene de desarrolladoras autorizadas. Como autora del canal, es necesario que especifique la lista de desarrolladoras autorizadas en el archivo .guix-authorizations del repositorio Git del canal. Las reglas para la verificación son simples: cada revisión debe firmarse con una de las claves enumeradas en el archivo .guix-authorizations de la revisión o revisiones anteriores¹⁴ El archivo .guix-authorizations tiene está estructura básica:

;; Archivo '.guix-authorizations' de ejemplo.

(authorizations
 (version 0)               ;versión de formato actual

 (("AD17 A21E F8AE D8F1 CC02  DBD9 F8AE D8F1 765C 61E3"
   (name "alicia"))
  ("CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"
   (name "carlos"))
  ("2A39 3FFF 68F4 EF7A 3D29  12AF 68F4 EF7A 22FB B2D5"
   (name "rober"))))

Cada huella va seguida de pares clave/valor opcionales, como en el ejemplo siguiente. Actualmente se ignoran dichos pares.

Estas reglas de verificación dan lugar a un problema “del huevo y la gallina”: ¿cómo se verifica la primera revisión? En relación con esto: ¿cómo se gestionan los canales cuyo repositorio tiene en su historia revisiones sin firmar y carece del archivo .guix-authorizations? ¿Y cómo creamos un nuevo canal separado en base a un canal ya existente?

Channel introductions answer these questions by describing the first commit of a channel that should be authenticated. The first time a channel is fetched with guix pull or guix time-machine, the command looks up the introductory commit and verifies that it is signed by the specified OpenPGP key. From then on, it authenticates commits according to the rule above. Authentication fails if the target commit is neither a descendant nor an ancestor of the introductory commit.

De manera adicional, su canal debe proporcionar todas las claves públicas que hayan sido mencionadas en .guix-authorizations, almacenadas como archivos .key, los cuales pueden ser binarios o tener “armadura ASCII”. De manera predeterminada, esos archivos .key se buscan en la rama llamada keyring pero puede especificar una rama diferente en .guix-channel de este modo:

(channel
  (version 0)
  (keyring-reference "mi-rama-de-claves"))

En resumen, como autora de un canal, hay tres cosas que debe hacer para permitir que las usuarias verifiquen su código:

1. Exportar las claves OpenPGP de quienes contribuyan en el presente y quienes hayan contribuido en el pasado con gpg --export y almacenarlas en archivos .key, de manera predeterminada en una rama llamada keyring (recomendamos que sea una rama huérfana).
2. Introducir un archivo inicial .guix-authorizations en el repositorio del canal. Hágalo con una revisión firmada (see Acceso al repositorio, para más información sobre cómo firmar revisiones).
3. Anuncie la presentación del canal, por ejemplo, en la página web de su canal. La presentación del canal, como hemos visto antes, es el par revisión/clave—es decir, la revisión que introdujo el archivo .guix-authorizations, y la huella de la clave de OpenPGP usada para firmarlo.

Before pushing to your public Git repository, you can run guix git authenticate to verify that you did sign all the commits you are about to push with an authorized key:

guix git authenticate revisión firma

donde revisión y firma son la presentación de su canal. See Invocación de guix git authenticate, para obtener más detalles.

Publicar un canal firmado requiere disciplina: cualquier error, como una revisión sin firmar o una revisión firmada por una clave no autorizada, evitará que las usuarias obtengan nuevas versiones de su canal—bueno, ¡ese es principalmente el objetivo de la verificación! Preste especial atención a la mezcla de ramas: las revisiones de mezcla se consideran auténticas únicamente en caso de que la clave que firma esté presente en el archivo .guix-authorizations de ambas ramas.

6.11 URL primaria

Las autoras pueden declarar la URL primaria del repositorio Git de su canal en el archivo .guix-channel de esta manera:

(channel
  (version 0)
  (url "https://example.org/guix.git"))

This allows guix pull to determine whether it is pulling code from a mirror of the channel; when that is the case, it warns the user that the mirror might be stale and displays the primary URL. That way, users cannot be tricked into fetching code from a stale mirror that does not receive security updates.

Esta caraterística únicamente tiene sentido en repositorios verificables, como el canal oficial guix, en el que guix pull se asegura de verificar la autenticidad del código que obtiene.

6.12 Escribir de noticias del canal

Las autoras los canales pueden querer ocasionalmente comunicar información a sus usuarias acerca de cambios importantes en el canal. Podrían mandar un correo a todo el mundo, pero esto no es tan conveniente.

En vez de eso, los canales proporcionan un archivo de noticias; cuando las usuarias de un canal ejecutan guix pull, dicho archivo de noticias se lee automáticamente y guix pull --news puede mostrar los anuncios que correspondan a las nuevas revisiones que se han obtenido, si existen.

Para hacerlo, las autoras del canal deben declarar primero el nombre del archivo de noticias en su archivo .guix-channel:

(channel
  (version 0)
  (news-file "etc/noticias.txt"))

El archivo de noticias en sí, etc/noticias.txt en este ejemplo, debe ser similar a este:

(channel-news
  (version 0)
  (entry (tag "the-bug-fix")
         (title (en "Fixed terrible bug")
                (fr "Oh la la")
                (es "Podemos volver a dormir en calma"))
         (body (en "@emph{Good news}!  It's fixed!")
               (eo "Certe ĝi pli bone funkcias nun!")
               (es "¡Al fin se ha corregido el error!")))
  (entry (commit "bdcabe815cd28144a2d2b4bc3c5057b051fa9906")
         (title (en "Added a great package")
                (ca "Què vol dir guix?")
                (es "Nuevo paquete añadido"))
         (body (en "Don't miss the @code{hello} package!")
               (es "Atención a la versátil herramienta @code{hello}"))))

Aunque el archivo de noticias use sintaxis de Scheme evite nombrarlo con .scm como extensión o se usará cuando se construya el canal, lo que emitirá un error debido a que no es un módulo válido. También puede mover el módulo del canal a un subdirectorio y almacenar el archivo de noticias en otro directorio.

Este archivo consiste en una lista de entradas de noticias. Cada entrada¹⁵ se asocia a una revisión o una etiqueta: describe los cambios llevados a cabo en ella, y posiblemente también en revisiones anteriores. Las usuarias ven las entradas únicamente la primera vez que obtienen la revisión a la que la entrada hace referencia.

El campo del título (title) debe ser un resumen de una línea mientras que el cuerpo de la noticia (body) puede ser arbitrariamente largo, y ambos pueden contener marcas de Texinfo (see Overview in GNU Texinfo). Tanto el título como el cuerpo son una lista de tuplas de etiqueta de lengua y mensaje, lo que permite a guix pull mostrar las noticias en la lengua que corresponde a la localización de la usuaria.

Si desea traducir las noticias siguiendo un flujo de trabajo basado en gettext, puede extraer las cadenas traducibles con xgettext (see xgettext Invocation in GNU Gettext Utilities). Por ejemplo, asumiendo que escribe las entradas de noticias primero en inglés, la siguiente orden crea un archivo PO que contiene las cadenas a traducir:

xgettext -o news.po -l scheme -ken etc/news.txt

En resumen, sí, puede usar su canal como un blog. Pero tenga en cuenta que esto puede que no sea exactamente lo que sus usuarias podrían esperar.

7.1 Invoking guix shell

The purpose of guix shell is to make it easy to create one-off software environments, without changing one’s profile. It is typically used to create development environments; it is also a convenient way to run applications without “polluting” your profile.

Nota: The guix shell command was recently introduced to supersede guix environment (see Invocación de guix environment). If you are familiar with guix environment, you will notice that it is similar but also—we hope!—more convenient.

La sintaxis general es:

guix shell [options] [package…]

The following example creates an environment containing Python and NumPy, building or downloading any missing package, and runs the python3 command in that environment:

guix shell python python-numpy -- python3

Note that it is necessary to include the main python package in this command even if it is already installed into your environment. This is so that the shell environment knows to set PYTHONPATH and other related variables. The shell environment cannot check the previously installed environment, because then it would be non-deterministic. This is true for most libraries: their corresponding language package should be included in the shell invocation.

Nota: guix shell can be also be used as a script interpreter, also known as shebang. Here is an example self-contained Python script making use of this feature:

#!/usr/bin/env -S guix shell python python-numpy -- python3
import numpy
print("This is numpy", numpy.version.version)

You may pass any guix shell option, but there’s one caveat: the Linux kernel has a limit of 127 bytes on shebang length.

Development environments can be created as in the example below, which spawns an interactive shell containing all the dependencies and environment variables needed to work on Inkscape:

guix shell --development inkscape

Exiting the shell places the user back in the original environment before guix shell was invoked. The next garbage collection (see Invocación de guix gc) may clean up packages that were installed in the environment and that are no longer used outside of it.

As an added convenience, guix shell will try to do what you mean when it is invoked interactively without any other arguments as in:

guix shell

If it finds a manifest.scm in the current working directory or any of its parents, it uses this manifest as though it was given via --manifest. Likewise, if it finds a guix.scm in the same directories, it uses it to build a development profile as though both --development and --file were present. In either case, the file will only be loaded if the directory it resides in is listed in ~/.config/guix/shell-authorized-directories. This provides an easy way to define, share, and enter development environments.

By default, the shell session or command runs in an augmented environment, where the new packages are added to search path environment variables such as PATH. You can, instead, choose to create an isolated environment containing nothing but the packages you asked for. Passing the --pure option clears environment variable definitions found in the parent environment¹⁶; passing --container goes one step further by spawning a container isolated from the rest of the system:

guix shell --container emacs gcc-toolchain

The command above spawns an interactive shell in a container where nothing but emacs, gcc-toolchain, and their dependencies is available. The container lacks network access and shares no files other than the current working directory with the surrounding environment. This is useful to prevent access to system-wide resources such as /usr/bin on foreign distros.

This --container option can also prove useful if you wish to run a security-sensitive application, such as a web browser, in an isolated environment. For example, the command below launches Ungoogled-Chromium in an isolated environment, which:

• shares network access with the host
• inherits host’s environment variables DISPLAY and XAUTHORITY
• has access to host’s authentication records from the XAUTHORITY file
• has no information about host’s current directory

guix shell --container --network --no-cwd ungoogled-chromium \
  --preserve='^XAUTHORITY$' --expose="${XAUTHORITY}" \
  --preserve='^DISPLAY$' -- chromium

guix shell defines the GUIX_ENVIRONMENT variable in the shell it spawns; its value is the file name of the profile of this environment. This allows users to, say, define a specific prompt for development environments in their .bashrc (see Bash Startup Files in The GNU Bash Reference Manual):

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

... o para explorar el perfil:

$ ls "$GUIX_ENVIRONMENT/bin"

Las opciones disponibles se resumen a continuación.

--check

Set up the environment and check whether the shell would clobber environment variables. It’s a good idea to use this option the first time you run guix shell for an interactive session to make sure your setup is correct.

For example, if the shell modifies the PATH environment variable, report it since you would get a different environment than what you asked for.

Such problems usually indicate that the shell startup files are unexpectedly modifying those environment variables. For example, if you are using Bash, make sure that environment variables are set or modified in ~/.bash_profile and not in ~/.bashrc—the former is sourced only by log-in shells. See Bash Startup Files in The GNU Bash Reference Manual, for details on Bash start-up files.

--development

-D

Cause guix shell to include in the environment the dependencies of the following package rather than the package itself. This can be combined with other packages. For instance, the command below starts an interactive shell containing the build-time dependencies of GNU Guile, plus Autoconf, Automake, and Libtool:

guix shell -D guile autoconf automake libtool

--expression=expr

-e expr

Crea un entorno para el paquete o lista de paquetes a los que evalúa expr.

Por ejemplo, ejecutando:

guix shell -D -e '(@ (gnu packages maths) petsc-openmpi)'

inicia un shell con el entorno para esta variante específica del paquete PETSc.

Ejecutar:

guix shell -e '(@ (gnu) %base-packages)'

inicia un shell con todos los paquetes básicos del sistema disponibles.

Las órdenes previas usan únicamente la salida predeterminada de los paquetes dados. Para seleccionar otras salidas, tuplas de dos elementos pueden ser especificadas:

guix shell -e '(list (@ (gnu packages bash) bash) "include")'

See package->development-manifest, for information on how to write a manifest for the development environment of a package.

--file=archivo

-f archivo

Create an environment containing the package or list of packages that the code within file evaluates to.

Como un ejemplo, archivo puede contener una definición como esta (see Definición de paquetes):

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package
  (inherit gdb)
  (native-inputs (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.69 automake texinfo))))

With the file above, you can enter a development environment for GDB by running:

guix shell -D -f gdb-devel.scm

--manifest=archivo

-m archivo

Crea un entorno para los paquetes contenidos en el objeto manifest devuelto por el código Scheme en file. Esta opción se puede repetir varias veces, en cuyo caso los manifiestos se concatenan.

Esto es similar a la opción del mismo nombre en guix package (see --manifest) y usa los mismos archivos de manifiesto.

See Writing Manifests, for information on how to write a manifest. See --export-manifest below on how to obtain a first manifest.

--export-manifest

Write to standard output a manifest suitable for --manifest corresponding to given command-line options.

This is a way to “convert” command-line arguments into a manifest. For example, imagine you are tired of typing long lines and would like to get a manifest equivalent to this command line:

guix shell -D guile git emacs emacs-geiser emacs-geiser-guile

Just add --export-manifest to the command line above:

guix shell --export-manifest \
  -D guile git emacs emacs-geiser emacs-geiser-guile

... and you get a manifest along these lines:

(concatenate-manifests
  (list (specifications->manifest
          (list "git"
                "emacs"
                "emacs-geiser"
                "emacs-geiser-guile"))
        (package->development-manifest
          (specification->package "guile"))))

You can store it into a file, say manifest.scm, and from there pass it to guix shell or indeed pretty much any guix command:

guix shell -m manifest.scm

Voilà, you’ve converted a long command line into a manifest! That conversion process honors package transformation options (see Opciones de transformación de paquetes) so it should be lossless.

--profile=perfil

-p perfil

Create an environment containing the packages installed in profile. Use guix package (see Invocación de guix package) to create and manage profiles.

--pure

Olvida las variables de entorno existentes cuando se construye un nuevo entorno, excepto aquellas especificadas con --preserve (véase más adelante). Esto tiene el efecto de crear un entorno en el que las rutas de búsqueda únicamente contienen las entradas del paquete.

--preserve=regexp

-E regexp

Cuando se usa junto a --pure, preserva las variables de entorno que corresponden con regexp—en otras palabras, las pone en una lista de variables de entorno que deben preservarse. Esta opción puede repetirse varias veces.

guix shell --pure --preserve=^SLURM openmpi … \
  -- mpirun …

Este ejemplo ejecuta mpirun en un contexto donde las únicas variables de entorno definidas son PATH, variables de entorno cuyo nombre empiece con ‘SLURM’, así como las variables “preciosas” habituales (HOME, USER, etc.).

--search-paths

Muestra las definiciones de variables de entorno que componen el entorno.

--system=sistema

-s sistema

Intenta construir para sistema—por ejemplo, i686-linux.

--container ¶

-C

Ejecuta la orden en un contenedor aislado. El directorio actual fuera del contenedor es asociado al interior del contenedor. Adicionalmente, a menos que se fuerce con --user, un directorio de prueba de la usuaria se crea de forma que coincida con el directorio actual de la usuaria, y /etc/passwd se configura adecuadamente.

El proceso lanzado se ejecuta como el usuario actual fuera del contenedor. Dentro del contenedor, tiene el mismo UID y GID que el usuario actual, a menos que se proporcione --user (véase más adelante).

--network

-N

Para contenedores, comparte el espacio de nombres de red con el sistema anfitrión. Los contenedores creados sin esta opción únicamente tienen acceso a la red local.

--link-profile

-P

For containers, link the environment profile to ~/.guix-profile within the container and set GUIX_ENVIRONMENT to that. This is equivalent to making ~/.guix-profile a symlink to the actual profile within the container. Linking will fail and abort the environment if the directory already exists, which will certainly be the case if guix shell was invoked in the user’s home directory.

Determinados paquetes se configuran para buscar en ~/.guix-profile archivos de configuración y datos;¹⁷ --link-profile permite a estos programas operar de la manera esperada dentro del entorno.

--user=usuaria

-u usuaria

Para contenedores, usa el nombre de usuaria usuaria en vez de la actual. La entrada generada en /etc/passwd dentro del contenedor contendrá el nombre usuaria; su directorio será /home/usuaria y ningún dato GECOS de la usuaria se copiará. Más aún, el UID y GID dentro del contenedor son 1000. usuaria no debe existir en el sistema.

Adicionalmente, cualquier ruta compartida o expuesta (véanse --share y --expose respectivamente) cuyo destino esté dentro de la carpeta actual de la usuaria será reasociada en relación a /home/usuaria; esto incluye la relación automática del directorio de trabajo actual.

# will expose paths as /home/foo/wd, /home/foo/test, and /home/foo/target
cd $HOME/wd
guix shell --container --user=foo \
     --expose=$HOME/test \
     --expose=/tmp/target=$HOME/target

Mientras esto limita el escape de la identidad de la usuaria a través de las rutas de sus directorios y cada uno de los campos de usuaria, esto es únicamente un componente útil de una solución de privacidad/anonimato más amplia—no una solución completa.

--no-cwd

El comportamiento predeterminado con contenedores es compartir el directorio de trabajo actual con el contenedor aislado e inmediatamente cambiar a dicho directorio dentro del contenedor. Si no se desea este comportamiento, --no-cwd indica que el directorio actual no se compartirá automáticamente y, en vez de cambiar a dicho directorio, se cambiará al directorio de la usuaria dentro del contenedor. Véase también --user.

--expose=fuente[=destino]

--share=fuente[=destino]

En contenedores, la --expose expone el sistema de archivos fuente del sistema anfitrión como un sistema de archivos de solo-lectura destino dentro del contenedor. --share de la misma manera expone el sistema de archivos con posibilidad de escritura. Si no se especifica destino, fuente se usa como el punto de montaje en el contenedor.

El ejemplo a continuación lanza una sesión interactiva de Guile en un contenedor donde el directorio principal de la usuaria es accesible en modo solo-lectura a través del directorio /intercambio:

guix shell --container --expose=$HOME=/exchange guile -- guile

--symlink=spec

-S spec

For containers, create the symbolic links specified by spec, as documented in pack-symlink-option.

--emulate-fhs

-F

When used with --container, emulate a Filesystem Hierarchy Standard (FHS) configuration within the container, providing /bin, /lib, and other directories and files specified by the FHS.

As Guix deviates from the FHS specification, this option sets up the container to more closely mimic that of other GNU/Linux distributions. This is useful for reproducing other development environments, testing, and using programs which expect the FHS specification to be followed. With this option, the container will include a version of glibc that will read /etc/ld.so.cache within the container for the shared library cache (contrary to glibc in regular Guix usage) and set up the expected FHS directories: /bin, /etc, /lib, and /usr from the container’s profile.

--nesting

-W

When used with --container, provide Guix inside the container and arrange so that it can interact with the build daemon that runs outside the container. This is useful if you want, within your isolated container, to create other containers, as in this sample session:

$ guix shell -CW coreutils
[env]$ guix shell -C guile -- guile -c '(display "hello!\n")'
hello!
[env]$ exit

The session above starts a container with coreutils programs available in PATH. From there, we spawn guix shell to create a nested container that provides nothing but Guile.

Another example is evaluating a guix.scm file that is untrusted, as shown here:

guix shell -CW -- guix build -f guix.scm

The guix build command as executed above can only access the current directory.

Under the hood, the -W option does several things:

• map the daemon’s socket (by default /var/guix/daemon-socket/socket) inside the container;
• map the whole store (by default /gnu/store) inside the container such that store items made available by nested guix invocations are visible;
• add the currently-used guix command to the profile in the container, such that guix describe returns the same state inside and outside the container;
• share the cache (by default ~/.cache/guix) with the host, to speed up operations such as guix time-machine and guix shell.

--rebuild-cache ¶

In most cases, guix shell caches the environment so that subsequent uses are instantaneous. Least-recently used cache entries are periodically removed. The cache is also invalidated, when using --file or --manifest, anytime the corresponding file is modified.

The --rebuild-cache forces the cached environment to be refreshed. This is useful when using --file or --manifest and the guix.scm or manifest.scm file has external dependencies, or if its behavior depends, say, on environment variables.

--root=archivo ¶

-r archivo

Hace que archivo sea un enlace simbólico al perfil para este entorno, y lo registra como una raíz del recolector de basura.

Esto es útil si desea proteger su entorno de la recolección de basura, hacerlo “persistente”.

When this option is omitted, guix shell caches profiles so that subsequent uses of the same environment are instantaneous—this is comparable to using --root except that guix shell takes care of periodically removing the least-recently used garbage collector roots.

In some cases, guix shell does not cache profiles—e.g., if transformation options such as --with-latest are used. In those cases, the environment is protected from garbage collection only for the duration of the guix shell session. This means that next time you recreate the same environment, you could have to rebuild or re-download packages.

See Invocación de guix gc, for more on GC roots.

guix shell also supports all of the common build options that guix build supports (see Opciones comunes de construcción) as well as package transformation options (see Opciones de transformación de paquetes).

7.2 Invocación de guix environment

The purpose of guix environment is to assist in creating development environments.

Deprecation warning: The guix environment command is deprecated in favor of guix shell, which performs similar functions but is more convenient to use. See Invoking guix shell.

Being deprecated, guix environment is slated for eventual removal, but the Guix project is committed to keeping it until May 1st, 2023. Please get in touch with us at guix-devel@gnu.org if you would like to discuss it.

La sintaxis general es:

guix environment opciones paquete…

El ejemplo siguiente lanza un nuevo shell preparado para el desarrollo de GNU Guile:

guix environment guile

Si las dependencias necesarias no están construidas todavía, guix environment las construye automáticamente. El entorno del nuevo shell es una versión aumentada del entorno en el que guix environment se ejecutó. Contiene las rutas de búsqueda necesarias para la construcción del paquete proporcionado añadidas a las variables ya existentes. Para crear un entorno “puro”, donde las variables de entorno previas no existen, use la opción --pure¹⁸.

Exiting from a Guix environment is the same as exiting from the shell, and will place the user back in the old environment before guix environment was invoked. The next garbage collection (see Invocación de guix gc) will clean up packages that were installed from within the environment and are no longer used outside of it.

guix environment define la variable GUIX_ENVIRONMENT en el shell que lanza; su valor es el nombre de archivo del perfil para este entorno. Esto permite a las usuarias, digamos, definir un prompt para entornos de desarrollo en su .bashrc (see Bash Startup Files in The GNU Bash Reference Manual):

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

... o para explorar el perfil:

$ ls "$GUIX_ENVIRONMENT/bin"

Adicionalmente, más de un paquete puede ser especificado, en cuyo caso se usa la unión de las entradas de los paquetes proporcionados. Por ejemplo, la siguiente orden lanza un shell donde todas las dependencias tanto de Guile como de Emacs están disponibles:

guix environment guile emacs

A veces no se desea una sesión interactiva de shell. Una orden arbitraria se puede invocar usando el valor -- para separar la orden del resto de los parámetros:

guix environment guile -- make -j4

In other situations, it is more convenient to specify the list of packages needed in the environment. For example, the following command runs python from an environment containing Python 3 and NumPy:

guix environment --ad-hoc python-numpy python -- python3

Es más, se pueden desear las dependencias de un paquete y también algunos paquetes adicionales que no son dependencias ni en tiempo de construcción ni en el de ejecución, pero son útiles no obstante para el desarrollo. Por esta razón, la opción --ad-hoc es posicional. Los paquetes que aparecen antes de --ad-hoc se interpretan como paquetes cuyas dependencias se añadirán al entorno. Los paquetes que aparecen después se interpretan como paquetes que se añadirán directamente al entorno. Por ejemplo, la siguiente orden crea un entorno de desarrollo Guix que incluye adicionalmente Git y strace:

guix environment --pure guix --ad-hoc git strace

En ocasiones es deseable aislar el entorno tanto como sea posible, para obtener la máxima pureza y reproducibilidad. En particular, cuando se usa Guix en una distribución anfitriona que no es el sistema Guix, es deseable prevenir acceso a /usr/bin y otros recursos del sistema desde el entorno de desarrollo. Por ejemplo, la siguiente orden lanza un REPL Guile en un “contenedor” donde únicamente el almacén y el directorio actual están montados:

guix environment --ad-hoc --container guile -- guile

Nota: La opción --container requiere Linux-libre 3.19 o posterior.

Otro caso de uso típico para los contenedores es la ejecución de aplicaciones sensibles como navegadores web. Para ejecutar Eolie, debemos exponer y compartir algunos archivos y directorios; incluimos nss-certs y exponemos /etc/ssl/certs/ para la identificación HTTPS; por último preservamos la variable de entorno DISPLAY ya que las aplicaciones gráficas en el contenedor no se mostrarían sin ella.

guix environment --preserve='^DISPLAY$' --container --network \
  --expose=/etc/machine-id \
  --expose=/etc/ssl/certs/ \
  --share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \
  --ad-hoc eolie nss-certs dbus --  eolie

Las opciones disponibles se resumen a continuación.

--check

Set up the environment and check whether the shell would clobber environment variables. See --check, for more info.

--root=archivo ¶

-r archivo

Hace que archivo sea un enlace simbólico al perfil para este entorno, y lo registra como una raíz del recolector de basura.

Esto es útil si desea proteger su entorno de la recolección de basura, hacerlo “persistente”.

Cuando se omite esta opción, el entorno se protege de la recolección de basura únicamente por la duración de la sesión guix environment. Esto significa que la siguiente vez que vuelva a crear el mismo entorno, puede tener que reconstruir o volver a descargar paquetes. See Invocación de guix gc, para más información sobre las raíces del recolector de basura.

--expression=expr

-e expr

Crea un entorno para el paquete o lista de paquetes a los que evalúa expr.

Por ejemplo, ejecutando:

guix environment -e '(@ (gnu packages maths) petsc-openmpi)'

inicia un shell con el entorno para esta variante específica del paquete PETSc.

Ejecutar:

guix environment --ad-hoc -e '(@ (gnu) %base-packages)'

inicia un shell con todos los paquetes básicos del sistema disponibles.

Las órdenes previas usan únicamente la salida predeterminada de los paquetes dados. Para seleccionar otras salidas, tuplas de dos elementos pueden ser especificadas:

guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'

--load=archivo

-l archivo

Crea un entorno para el paquete o la lista de paquetes a la que el código en archivo evalúa.

Como un ejemplo, archivo puede contener una definición como esta (see Definición de paquetes):

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package
  (inherit gdb)
  (native-inputs (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.69 automake texinfo))))

--manifest=archivo

-m archivo

Crea un entorno para los paquetes contenidos en el objeto manifest devuelto por el código Scheme en file. Esta opción se puede repetir varias veces, en cuyo caso los manifiestos se concatenan.

Esto es similar a la opción del mismo nombre en guix package (see --manifest) y usa los mismos archivos de manifiesto.

See guix shell --export-manifest, for information on how to “convert” command-line options into a manifest.

--ad-hoc

Incluye todos los paquetes especificados en el entorno resultante, como si un paquete ad hoc hubiese sido definido con ellos como entradas. Esta opción es útil para la creación rápida un entorno sin tener que escribir una expresión de paquete que contenga las entradas deseadas.

Por ejemplo, la orden:

guix environment --ad-hoc guile guile-sdl -- guile

ejecuta guile en un entorno donde están disponibles Guile y Guile-SDL.

Fíjese que este ejemplo solicita implícitamente la salida predeterminada de guile y guile-sdl, pero es posible solicitar una salida específica—por ejemplo, glib:bin solicita la salida bin de glib (see Paquetes con múltiples salidas).

Esta opción puede componerse con el comportamiento predeterminado de guix environment. Los paquetes que aparecen antes de --ad-hoc se interpretan como paquetes cuyas dependencias se añadirán al entorno, el comportamiento predefinido. Los paquetes que aparecen después se interpretan como paquetes a añadir directamente al entorno.

--profile=perfil

-p perfil

Create an environment containing the packages installed in profile. Use guix package (see Invocación de guix package) to create and manage profiles.

--pure

Olvida las variables de entorno existentes cuando se construye un nuevo entorno, excepto aquellas especificadas con --preserve (véase más adelante). Esto tiene el efecto de crear un entorno en el que las rutas de búsqueda únicamente contienen las entradas del paquete.

--preserve=regexp

-E regexp

Cuando se usa junto a --pure, preserva las variables de entorno que corresponden con regexp—en otras palabras, las pone en una lista de variables de entorno que deben preservarse. Esta opción puede repetirse varias veces.

guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \
  -- mpirun …

Este ejemplo ejecuta mpirun en un contexto donde las únicas variables de entorno definidas son PATH, variables de entorno cuyo nombre empiece con ‘SLURM’, así como las variables “preciosas” habituales (HOME, USER, etc.).

--search-paths

Muestra las definiciones de variables de entorno que componen el entorno.

--system=sistema

-s sistema

Intenta construir para sistema—por ejemplo, i686-linux.

--container ¶

-C

Ejecuta la orden en un contenedor aislado. El directorio actual fuera del contenedor es asociado al interior del contenedor. Adicionalmente, a menos que se fuerce con --user, un directorio de prueba de la usuaria se crea de forma que coincida con el directorio actual de la usuaria, y /etc/passwd se configura adecuadamente.

El proceso lanzado se ejecuta como el usuario actual fuera del contenedor. Dentro del contenedor, tiene el mismo UID y GID que el usuario actual, a menos que se proporcione --user (véase más adelante).

--network

-N

Para contenedores, comparte el espacio de nombres de red con el sistema anfitrión. Los contenedores creados sin esta opción únicamente tienen acceso a la red local.

--link-profile

-P

Para contenedores, enlaza el perfil del entorno a ~/.guix-profile dentro del contenedor y asigna ese valor a GUIX_ENVIRONMENT. Es equivalente a que ~/.guix-profile sea un enlace al perfil real dentro del contenedor. El enlace fallará e interrumpirá el entorno si el directorio ya existe, lo cual será probablemente el caso si guix environment se invocó en el directorio de la usuaria.

Determinados paquetes se configuran para buscar en ~/.guix-profile archivos de configuración y datos;¹⁹ --link-profile permite a estos programas operar de la manera esperada dentro del entorno.

--user=usuaria

-u usuaria

Para contenedores, usa el nombre de usuaria usuaria en vez de la actual. La entrada generada en /etc/passwd dentro del contenedor contendrá el nombre usuaria; su directorio será /home/usuaria y ningún dato GECOS de la usuaria se copiará. Más aún, el UID y GID dentro del contenedor son 1000. usuaria no debe existir en el sistema.

Adicionalmente, cualquier ruta compartida o expuesta (véanse --share y --expose respectivamente) cuyo destino esté dentro de la carpeta actual de la usuaria será reasociada en relación a /home/usuaria; esto incluye la relación automática del directorio de trabajo actual.

# expondrá las rutas /home/foo/ddt, /home/foo/prueba y /home/foo/objetivo
cd $HOME/ddt
guix environment --container --user=foo \
     --expose=$HOME/prueba \
     --expose=/tmp/objetivo=$HOME/objetivo

Mientras esto limita el escape de la identidad de la usuaria a través de las rutas de sus directorios y cada uno de los campos de usuaria, esto es únicamente un componente útil de una solución de privacidad/anonimato más amplia—no una solución completa.

--no-cwd

El comportamiento predeterminado con contenedores es compartir el directorio de trabajo actual con el contenedor aislado e inmediatamente cambiar a dicho directorio dentro del contenedor. Si no se desea este comportamiento, --no-cwd indica que el directorio actual no se compartirá automáticamente y, en vez de cambiar a dicho directorio, se cambiará al directorio de la usuaria dentro del contenedor. Véase también --user.

--expose=fuente[=destino]

--share=fuente[=destino]

En contenedores, la --expose expone el sistema de archivos fuente del sistema anfitrión como un sistema de archivos de solo-lectura destino dentro del contenedor. --share de la misma manera expone el sistema de archivos con posibilidad de escritura. Si no se especifica destino, fuente se usa como el punto de montaje en el contenedor.

El ejemplo a continuación lanza una sesión interactiva de Guile en un contenedor donde el directorio principal de la usuaria es accesible en modo solo-lectura a través del directorio /intercambio:

guix environment --container --expose=$HOME=/intercambio --ad-hoc guile -- guile

--emulate-fhs

-F

For containers, emulate a Filesystem Hierarchy Standard (FHS) configuration within the container, see the official specification. As Guix deviates from the FHS specification, this option sets up the container to more closely mimic that of other GNU/Linux distributions. This is useful for reproducing other development environments, testing, and using programs which expect the FHS specification to be followed. With this option, the container will include a version of glibc which will read /etc/ld.so.cache within the container for the shared library cache (contrary to glibc in regular Guix usage) and set up the expected FHS directories: /bin, /etc, /lib, and /usr from the container’s profile.

Además, guix environment acepta todas las opciones comunes de construcción que permite guix build (see Opciones comunes de construcción) así como las opciones de transformación de paquetes (see Opciones de transformación de paquetes).

7.3 Invocación de guix pack

De manera ocasional querrá dar software a gente que (¡todavía!) no tiene la suerte de usar Guix. Usted les diría que ejecuten guix package -i algo, pero eso no es posible en este caso. Aquí es donde viene guix pack.

Nota: Si está buscando formas de intercambiar binarios entre máquinas que ya ejecutan Guix, see Invocación de guix copy, Invocación de guix publish, y Invocación de guix archive.

La orden guix pack crea un paquete reducido o empaquetado de software: crea un archivador tar u otro tipo que contiene los binarios del software en el que está interesada y todas sus dependencias. El archivo resultante puede ser usado en una máquina que no tiene Guix, y la gente puede ejecutar exactamente los mismos binarios que usted tiene con Guix. El paquete en sí es creado de forma reproducible bit-a-bit, para que cualquiera pueda verificar que realmente contiene los resultados de construcción que pretende distribuir.

Por ejemplo, para crear un empaquetado que contenga Guile, Emacs, Geiser y todas sus dependencias, puede ejecutar:

$ guix pack guile emacs emacs-geiser
…
/gnu/store/…-pack.tar.gz

El resultado aquí es un archivador tar que contiene un directorio de /gnu/store con todos los paquetes relevantes. El archivador resultante contiene un perfil con los tres paquetes de interés; el perfil es el mismo que se hubiera creado por guix package -i. Este es el mecanismo usado para crear el propio archivador de binarios separado de Guix (see Instalación binaria).

Las usuarias de este empaquetad tendrán que ejecutar /gnu/store/…-profile/bin/guile para ejecutar guile, lo que puede resultar inconveniente. Para evitarlo, puede crear, digamos, un enlace simbólico /opt/gnu/bin al perfil:

guix pack -S /opt/gnu/bin=bin guile emacs emacs-geiser

De este modo, las usuarias pueden escribir alegremente /opt/gnu/bin/guile y disfrutar.

¿Qué pasa se la receptora de su paquete no tiene privilegios de root en su máquina y por lo tanto no puede desempaquetarlo en la raíz del sistema de archivos? En ese caso, lo que usted desea es usar la opción --relocatable (véase a continuación). Esta opción produce binarios reposicionables, significando que pueden ser colocados en cualquier lugar de la jerarquía del sistema de archivos: en el ejemplo anterior, las usuarias pueden desempaquetar el archivador en su directorio de usuaria y ejecutar directamente ./opt/gnu/bin/guile.

De manera alternativa, puede producir un empaquetado en el formato de imagen Docker usando la siguiente orden:

guix pack -f docker -S /bin=bin guile guile-readline

El resultado es un archivador “tar” que puede ser proporcionado a la orden docker load, seguida de docker run:

docker load < archivo
docker run -ti guile-guile-readline /bin/guile

where file is the image returned by guix pack, and guile-guile-readline is its “image tag”. See the Docker documentation for more information.

Otra opción más es producir una imagen SquashFS con la siguiente orden:

guix pack -f squashfs bash guile emacs emacs-geiser

El resultado es una imagen de sistema de archivos SquashFS que puede ser o bien montada, o bien usada directamente como una imagen contenedora de sistemas de archivos con el entorno de ejecución de contenedores Singularity, usando órdenes como singularity shell o singularity exec.

Varias opciones de la línea de órdenes le permiten personalizar su empaquetado:

--format=formato

-f formato

Produce un empaquetado en el formato específico.

Los formatos disponibles son:

tarball

Es el formato predeterminado. Produce un archivador que contiene todos los binarios y enlaces simbólicos especificados.

docker

This produces a tarball that follows the Docker Image Specification. By default, the “repository name” as it appears in the output of the docker images command is computed from package names passed on the command line or in the manifest file. Alternatively, the “repository name” can also be configured via the --image-tag option. Refer to --help-docker-format for more information on such advanced options.

squashfs

Produce una imagen SquashFS que contiene todos los binarios y enlaces simbólicos especificados, así como puntos de montaje vacíos para sistemas de archivos virtuales como procfs.

Nota: Singularity necesita que proporcione /bin/sh en la imagen. Por esta razón, guix pack -f squashfs siempre implica -S /bin=bin. Por tanto, su invocación de guix pack debe siempre comenzar de manera similar a esta:

guix pack -f squashfs bash …

Si se olvida del paquete bash (o similar), singularity run y singularity exec fallarán con el mensaje “no existe el archivo o directorio”, lo que no sirve de ayuda.

deb ¶

This produces a Debian archive (a package with the ‘.deb’ file extension) containing all the specified binaries and symbolic links, that can be installed on top of any dpkg-based GNU(/Linux) distribution. Advanced options can be revealed via the --help-deb-format option. They allow embedding control files for more fine-grained control, such as activating specific triggers or providing a maintainer configure script to run arbitrary setup code upon installation.

guix pack -f deb -C xz -S /usr/bin/hello=bin/hello hello

Nota: Because archives produced with guix pack contain a collection of store items and because each dpkg package must not have conflicting files, in practice that means you likely won’t be able to install more than one such archive on a given system. You can nonetheless pack as many Guix packages as you want in one such archive.

Aviso: dpkg will assume ownership of any files contained in the pack that it does not know about. It is unwise to install Guix-produced ‘.deb’ files on a system where /gnu/store is shared by other software, such as a Guix installation or other, non-deb packs.

rpm ¶

This produces an RPM archive (a package with the ‘.rpm’ file extension) containing all the specified binaries and symbolic links, that can be installed on top of any RPM-based GNU/Linux distribution. The RPM format embeds checksums for every file it contains, which the rpm command uses to validate the integrity of the archive.

Advanced RPM-related options are revealed via the --help-rpm-format option. These options allow embedding maintainer scripts that can run before or after the installation of the RPM archive, for example.

The RPM format supports relocatable packages via the --prefix option of the rpm command, which can be handy to install an RPM package to a specific prefix.

guix pack -f rpm -R -C xz -S /usr/bin/hello=bin/hello hello

sudo rpm --install --prefix=/opt /gnu/store/...-hello.rpm

Nota: Contrary to Debian packages, conflicting but identical files in RPM packages can be installed simultaneously, which means multiple guix pack-produced RPM packages can usually be installed side by side without any problem.

Aviso: rpm assumes ownership of any files contained in the pack, which means it will remove /gnu/store upon uninstalling a Guix-generated RPM package, unless the RPM package was installed with the --prefix option of the rpm command. It is unwise to install Guix-produced ‘.rpm’ packages on a system where /gnu/store is shared by other software, such as a Guix installation or other, non-rpm packs.

--relocatable

-R

Produce binarios reposicionables—es decir, binarios que se pueden encontrar en cualquier lugar de la jerarquía del sistema de archivos, y ejecutarse desde allí.

Cuando se proporciona una vez la opción, los binarios resultantes necesitan la implementación de espacios de nombres de usuaria del núcleo Linux; cuando se proporciona dos veces²⁰, los binarios reposicionables usan otras técnicas si los espacios de nombres de usuaria no están disponibles, y funcionan esencialmente en cualquier sitio—véase más adelante las implicaciones.

Por ejemplo, si crea un empaquetado que contiene Bash con:

guix pack -RR -S /mybin=bin bash

... puede copiar ese empaquetado a una máquina que no tiene Guix, y desde su directorio, como una usuaria normal, ejecutar:

tar xf pack.tar.gz
./mibin/sh

En ese shell, si escribe ls /gnu/store, notará que /gnu/store muestra y contiene todas las dependencias de bash, ¡incluso cuando la máquina no tiene el directorio /gnu/store! Esto es probablemente el modo más simple de desplegar software construido en Guix en una máquina no-Guix.

Nota: No obstante hay un punto a tener en cuenta: esta técnica descansa en la característica de espacios de nombres de usuaria del núcleo Linux, la cual permite a usuarias no privilegiadas montar o cambiar la raíz. Versiones antiguas de Linux no los implementan, y algunas distribuciones GNU/Linux los desactivan.

Para producir binarios reposicionables que funcionen incluso en ausencia de espacios de nombre de usuaria, proporcione --relocatable o -R dos veces. En ese caso, los binarios intentarán el uso de espacios de nombres de usuaria y usarán otro motor de ejecución si los espacios de nombres no están disponibles. Existe implementación para siguientes motores de ejecución:

default

Intenta usar espacios de nombres de usuaria y usa PRoot en caso de no estar disponibles (véase a continuación).

performance

Intenta usar espacios de nombres de usuaria y usa Fakechroot en caso de no estar disponibles (véase a continuación).

userns

Usa espacios de nombres de usuaria o aborta el programa si no están disponibles.

proot

Ejecución a través de PRoot. El programa PRoot proporciona el soporte necesario para la virtualización del sistema de archivos. Lo consigue mediante el uso de la llamada al sistema ptrace en el programa en ejecución. Esta aproximación tiene la ventaja de funcionar sin soporte especial en el núcleo, pero incurre en una sobrecarga en el tiempo de ejecución cada vez que se realiza una llamada al sistema.

fakechroot

Ejecución a través de Fakechroot. Fakechroot virtualiza los accesos al sistema de archivos interceptando las llamadas a las funciones de la biblioteca de C como open, stat, exec, etcétera. Al contrario que PRoot, el proceso se somete únicamente a una pequeña sobrecarga. No obstante, no siempre funciona: algunos accesos realizados dentro de la biblioteca de C no se interceptan, ni tampoco los accesos al sistema de archivos a través de llamadas al sistema directas, lo que puede provocar un comportamiento impredecible.

Cuando ejecute un programa recubierto puede solicitar explícitamente uno de los motores de ejecución enumerados previamente proporcionando el valor adecuado a la variable de entorno GUIX_EXECUTION_ENGINE.

--entry-point=orden

Usa orden como el punto de entrada del empaquetado resultante, si el formato de empaquetado lo permite—actualmente docker y squashfs (Singularity) lo permiten. orden debe ser una ruta relativa al perfil contenido en el empaquetado.

El punto de entrada especifica la orden que herramientas como docker run o singularity run arrancan de manera automática de forma predeterminada. Por ejemplo, puede ejecutar:

guix pack -f docker --entry-point=bin/guile guile

El empaquetado resultante puede cargarse fácilmente y docker run sin parámetros adicionales lanzará bin/guile:

docker load -i pack.tar.gz
docker run image-id

--entry-point-argument=command

-A command

Use command as an argument to entry point of the resulting pack. This option is only valid in conjunction with --entry-point and can appear multiple times on the command line.

guix pack -f docker --entry-point=bin/guile --entry-point-argument="--help" guile

--max-layers=n

Specifies the maximum number of Docker image layers allowed when building an image.

guix pack -f docker --max-layers=100 guile

This option allows you to limit the number of layers in a Docker image. Docker images are comprised of multiple layers, and each layer adds to the overall size and complexity of the image. By setting a maximum number of layers, you can control the following effects:

• Disk Usage: Increasing the number of layers can help optimize the disk space required to store multiple images built with a similar package graph.
• Pulling: When transferring images between different nodes or systems, having more layers can reduce the time required to pull the image.

--expression=expr

-e expr

Considera el paquete al que evalúa expr

Su propósito es idéntico a la opción del mismo nombre en guix build (see --expression en guix build).

--manifest=archivo

-m archivo

Usa los paquetes contenidos en el objeto manifest devuelto por el código Scheme en archivo. Esta opción puede repetirse varias veces, en cuyo caso los manifiestos se concatenan.

Esto tiene un propósito similar al de la opción del mismo nombre en guix package (see --manifest) y usa los mismos archivos de manifiesto. Esto le permite definir una colección de paquetes una vez y usarla tanto para crear perfiles como para crear archivos en máquinas que no tienen instalado Guix. Fíjese que puede especificar o bien un archivo de manifiesto o bien una lista de paquetes, pero no ambas.

See Writing Manifests, for information on how to write a manifest. See guix shell --export-manifest, for information on how to “convert” command-line options into a manifest.

--system=sistema

-s sistema

Intenta construir paquetes para sistema—por ejemplo, x86_64-linux—en vez del tipo de sistema de la máquina de construcción.

--target=tripleta ¶

Compilación cruzada para la tripleta, que debe ser una tripleta GNU válida, cómo "aarch64-linux-gnu" (see GNU configuration triplets in Autoconf).

--compression=herramienta

-C herramienta

Comprime el archivador resultante usando herramienta—un valor que puede ser gzip, zstd, bzip2, xz, lzip o none para no usar compresión.

--symlink=spec

-S spec

Añade los enlaces simbólicos especificados por spec al empaquetado. Esta opción puede aparecer varias veces.

La forma de spec es fuente=destino, donde fuente es el enlace simbólico que será creado y destino es el destino del enlace simbólico.

Por ejemplo, -S /opt/gnu/bin=bin crea un enlace simbólico /opt/gnu/bin apuntando al subdirectorio bin del perfil.

--save-provenance

Almacena la información de procedencia para paquetes proporcionados en la línea de órdenes. La información de procedencia incluye la URL y revisión de los canales en uso (see Canales).

La información de procedencia se almacena en el archivo /gnu/store/…-profile/manifest dentro del empaquetado, junto a los metadatos habituales del paquete—el nombre y la versión de cada paquete, sus entradas propagadas, etcétera. Es información útil para la parte receptora del empaquetado, quien de ese modo conoce como se obtuvo (supuestamente) dicho empaquetado.

Esta opción no se usa de manera predeterminada debido a que, como las marcas de tiempo, la información de procedencia no aportan nada al proceso de construcción. En otras palabras, hay una infinidad de URL de canales e identificadores de revisiones que pueden llevar al mismo empaquetado. Almacenar estos metadatos “silenciosos” en la salida puede potencialmente romper la propiedad de reproducibilidad bit a bit entre fuentes y binarios.

--root=archivo ¶

-r archivo

Hace que archivo sea un enlace simbólico al empaquetado resultante, y lo registra como una raíz del recolector de basura.

--localstatedir

--profile-name=nombre

Incluye el “directorio de estado local”, /var/guix, en el empaquetado resultante, y notablemente el perfil /var/guix/profiles/per-user/root/nombre—por defecto nombre es guix-profile, que corresponde con ~root/.guix-profile.

/var/guix contiene la base de datos del almacén (see El almacén) así como las raíces del recolector de basura (see Invocación de guix gc). Proporcionarlo junto al empaquetado significa que el almacén está “completo” y Guix puede trabajar con él; no proporcionarlo significa que el almacén está “muerto”: no se pueden añadir o borrar nuevos elementos después de la extracción del empaquetado.

Un caso de uso para esto es el archivador tar autocontenido de binarios de Guix (see Instalación binaria).

--derivation

-d

Imprime el nombre de la derivación que construye el empaquetado.

--bootstrap

Usa los binarios del lanzamiento para construir el empaquetado. Esta opción es útil únicamente a las desarrolladoras de Guix.

Además, guix pack acepta todas las opciones comunes de construcción (see Opciones comunes de construcción) y todas las opciones de transformación de paquetes (see Opciones de transformación de paquetes).

7.4 La cadena de herramientas de GCC

Si necesita una cadena de herramientas de desarrollo completa para compilar y enlazar código fuente C o C++, use el paquete gcc-toolchain. Este paquete proporciona una cadena de herramientas GCC para desarrollo C/C++, incluyendo el propio GCC, la biblioteca de C GNU (cabeceras y binarios, más símbolos de depuración de la salida debug), Binutils y un recubrimiento del enlazador.

El propósito del recubrimiento es inspeccionar las opciones -L y -l proporcionadas al enlazador, y los correspondientes parámetros -rpath, y llamar al enlazador real con este nuevo conjunto de parámetros. Puede instruir al recubrimiento para rechazar el enlace contra bibliotecas que no se encuentren en el almacén proporcionando el valor no a la variable de entorno GUIX_LD_WRAPPER_ALLOW_IMPURITIES.

El paquete gfortran-toolchain proporciona una cadena de herramientas de desarrollo completa de GCC para desarrollo en Fortran. Para otros lenguajes por favor use ‘guix search gcc toolchain’ (see Invoking guix package).

7.5 Invocación de guix git authenticate

La orden guix git authenticate verifica una revisión de Git siguiendo las mismas reglas que con los canales (see verificación de canales). Es decir, empezando en una revisión dada, se asegura que todas las revisiones posteriores están firmadas por una clave OpenPGP cuya huella aparece en el archivo .guix-authorizations de su revisión o revisiones antecesoras.

Encontrará útil esta orden si mantiene un canal. Pero de hecho, este sistema de verificación es útil en un contexto más amplio, por lo que quizá quiera usarlo para repositorios de Git que no estén relacionados con Guix.

La sintaxis general es:

guix git authenticate revisión firma [opciones…]

By default, this command authenticates the Git checkout in the current directory; it outputs nothing and exits with exit code zero on success and non-zero on failure. commit above denotes the first commit where authentication takes place, and signer is the OpenPGP fingerprint of public key used to sign commit. Together, they form a channel introduction (see channel introduction). On your first successful run, the introduction is recorded in the .git/config file of your checkout, allowing you to omit them from subsequent invocations:

guix git authenticate [options…]

Should you have branches that require different introductions, you can specify them directly in .git/config. For example, if the branch called personal-fork has a different introduction than other branches, you can extend .git/config along these lines:

[guix "authentication-personal-fork"]
	introduction-commit = cabba936fd807b096b48283debdcddccfea3900d
	introduction-signer = C0FF EECA BBA9 E6A8 0D1D  E643 A2A0 6DF2 A33A 54FA
	keyring = keyring

The first run also attempts to install pre-push and post-merge hooks, such that guix git authenticate is invoked as soon as you run git push, git pull, and related commands; it does not overwrite preexisting hooks though.

The command-line options described below allow you to fine-tune the process.

--repository=directorio

-r directorio

Usa el repositorio Git en directorio en vez del directorio actual.

--keyring=referencia

-k referencia

Carga el anillo de claves desde referencia, la rama de referencia como por ejemplo origin/keyring o mi-anillo-de-claves. La rama debe contener las claves públicas de OpenPGP en archivos .key, binarios o con “armadura ASCII’. De manera predeterminada el anillo de claves se carga de la rama con nombre keyring.

--end=commit

Authenticate revisions up to commit.

--stats

Muestra las estadísticas de firmas de revisiones tras finalizar.

--cache-key=clave

Las revisiones verificadas previamente se almacenan en un archivo bajo ~/.cache/guix/authentication. Esta opción fuerza el almacenamiento en el archivo clave de dicho directorio.

--historical-authorizations=archivo

De manera predeterminada, cualquier revisión cuyo antecesor o antecesores carezcan del archivo .guix-authorizations no se considera auténtica. En contraste, esta opción considera las autorizaciones en archivo para cualquier revisión que carezca de .guix-authorizations. El formato de archivo es el mismo que el de .guix-authorizations (see formato de .guix-authorizations).

8.1 Módulos de paquetes

Desde un punto de vista programático, las definiciones de paquetes de la distribución GNU se proporcionan por módulos Guile en el espacio de nombres (gnu packages …)²¹ (see Guile modules in GNU Guile Reference Manual). Por ejemplo, el módulo (gnu packages emacs) exporta una variable con nombre emacs, que está asociada a un objeto <package> (see Definición de paquetes).

El espacio de nombres de módulos (gnu packages …) se recorre automáticamente en busca de paquetes en las herramientas de línea de ordenes. Por ejemplo, cuando se ejecuta guix install emacs, todos los módulos (gnu packages …) son procesados hasta encontrar uno que exporte un objeto de paquete cuyo nombre sea emacs. Esta búsqueda de paquetes se implementa en el módulo (gnu packages).

Las usuarias pueden almacenar definiciones de paquetes en módulos con nombres diferentes—por ejemplo, (mis-paquetes emacs)²². Existen dos maneras de hacer visibles estas definiciones de paquetes a las interfaces de usuaria:

1. Mediante la adición del directorio que contiene sus módulos de paquetes a la ruta de búsqueda con la opción -L de guix package y otras órdenes (see Opciones comunes de construcción), o usando la variable de entorno GUIX_PACKAGE_PATH descrita a continuación.
2. Mediante la definición de un canal y la configuración de guix pull de manera que se actualice desde él. Un canal es esencialmente un repositorio Git que contiene módulos de paquetes. See Canales, para más información sobre cómo definir y usar canales.

GUIX_PACKAGE_PATH funciona de forma similar a otras variables de rutas de búsqueda:

Variable de entorno: GUIX_PACKAGE_PATH

Es una lista separada por dos puntos de directorios en los que se buscarán módulos de paquetes adicionales. Los directorios enumerados en esta variable tienen preferencia sobre los propios módulos de la distribución.

La distribución es auto-contenida y completamente basada en el lanzamiento inicial: cada paquete se construye basado únicamente en otros paquetes de la distribución. La raíz de este grafo de dependencias es un pequeño conjunto de binarios del lanzamiento inicial, proporcionados por el módulo (gnu packages bootstrap). Para más información sobre el lanzamiento inicial, see Lanzamiento inicial.

8.2 Definición de paquetes

La interfaz de alto nivel de las definiciones de paquetes está implementada en los módulos (guix packages) y (guix build-system). Como un ejemplo, la definición de paquete, o receta, para el paquete GNU Hello es como sigue:

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs (list gawk))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

Sin ser una experta en Scheme—pero conociendo un poco de inglés—, la lectora puede haber supuesto el significado de varios campos aquí. Esta expresión asocia la variable hello al objeto <package>, que esencialmente es un registro (see Scheme records in GNU Guile Reference Manual). Este objeto de paquete puede ser inspeccionado usando los procedimientos encontrados en el módulo (guix packages); por ejemplo, (package-name hello) devuelve—¡sorpresa!—"hello".

Con suerte, puede que sea capaz de importar parte o toda la definición del paquete de su interés de otro repositorio, usando la orden guix import (see Invocación de guix import).

En el ejemplo previo, hello se define en un módulo para ella, (gnu packages hello). Técnicamente, esto no es estrictamente necesario, pero es conveniente hacerlo: todos los paquetes definidos en módulos bajo (gnu packages …) se reconocen automáticamente en las herramientas de línea de órdenes (see Módulos de paquetes).

Hay unos pocos puntos que merece la pena destacar de la definición de paquete previa:

• El campo source del paquete es un objeto <origin> (see Referencia de origin, para la referencia completa). Aquí se usa el método url-fetch de (guix download), lo que significa que la fuente es un archivo a descargar por FTP o HTTP.

  El prefijo mirror://gnu instruye a url-fetch para usar uno de los espejos GNU definidos en (guix download).

  El campo sha256 especifica el hash SHA256 esperado del archivo descargado. Es obligatorio, y permite a Guix comprobar la integridad del archivo. La forma (base32 …) introduce la representación base32 del hash. Puede obtener esta información con guix download (see Invocación de guix download) y guix hash (see Invocación de guix hash).

  Cuando sea necesario, la forma origin también puede tener un campo patches con la lista de parches a ser aplicados, y un campo snippet con una expresión Scheme para modificar el código fuente.

• El campo build-system especifica el procedimiento de construcción del paquete (see Sistemas de construcción). Aquí, gnu-build-system representa el familiar sistema de construcción GNU, donde los paquetes pueden configurarse, construirse e instalarse con la secuencia de ordenes habitual ./configure && make && make check && make install.

  Cuando comience a empaquetar software no trivial puede que necesite herramientas para manipular estas fases de construcción, manipular archivos, etcétera. See Utilidades de construcción para obtener más información sobre este tema.

• El campo arguments especifica las opciones para el sistema de construcción (see Sistemas de construcción). Aquí son interpretadas por gnu-build-system como una petición de ejecutar configure con la opción --enable-silent-rules.

  What about these quote (') characters? They are Scheme syntax to introduce a literal list; ' is synonymous with quote. Sometimes you’ll also see ` (a backquote, synonymous with quasiquote) and , (a comma, synonymous with unquote). See quoting in GNU Guile Reference Manual, for details. Here the value of the arguments field is a list of arguments passed to the build system down the road, as with apply (see apply in GNU Guile Reference Manual).

  La secuencia almohadilla-dos puntos (#:) define una palabra clave Scheme (see Keywords in GNU Guile Reference Manual), y #:configure-flags es una palabra clave usada para pasar un parámetro nominal al sistema de construcción (see Coding With Keywords in GNU Guile Reference Manual).

• The inputs field specifies inputs to the build process—i.e., build-time or run-time dependencies of the package. Here, we add an input, a reference to the gawk variable; gawk is itself bound to a <package> object.

  Fíjese que no hace falta que GCC, Coreutils, Bash y otras herramientas esenciales se especifiquen como entradas aquí. En vez de eso, gnu-build-system se hace cargo de asegurar que están presentes (see Sistemas de construcción).

  No obstante, cualquier otra dependencia debe ser especificada en el campo inputs. Las dependencias no especificadas aquí simplemente no estarán disponibles para el proceso de construcción, provocando posiblemente un fallo de construcción.

See Referencia de package, para una descripción completa de los campos posibles.

Más allá: Intimidated by the Scheme language or curious about it? The Cookbook has a short section to get started that recaps some of the things shown above and explains the fundamentals. See A Scheme Crash Course in GNU Guix Cookbook, for more information.

Una vez la definición de paquete esté en su lugar, el paquete puede ser construido realmente usando la herramienta de línea de órdenes guix build (see Invocación de guix build), pudiendo resolver cualquier fallo de construcción que encuentre (see Depuración de fallos de construcción). Puede volver a la definición del paquete fácilmente usando la orden guix edit (see Invocación de guix edit). See Pautas de empaquetamiento, para más información sobre cómo probar definiciones de paquetes, y Invocación de guix lint, para información sobre cómo comprobar la consistencia del estilo de una definición. Por último, see Canales, para información sobre cómo extender la distribución añadiendo sus propias definiciones de paquetes en un “canal”.

Finalmente, la actualización de la definición con una nueva versión oficial puede ser automatizada parcialmente por la orden guix refresh (see Invocación de guix refresh).

Tras el telón, una derivación correspondiente al objeto <package> se calcula primero mediante el procedimiento package-derivation. Esta derivación se almacena en un archivo .drv bajo /gnu/store. Las acciones de construcción que prescribe pueden entonces llevarse a cabo usando el procedimiento build-derivations (see El almacén).

Procedimiento: package-derivation almacén paquete [sistema]

Devuelve el objeto <derivation> del paquete pra el sistema (see Derivaciones).

paquete debe ser un objeto <package> válido, y sistema debe ser una cadena que denote el tipo de sistema objetivo—por ejemplo, "x86_64-linux" para un sistema GNU x86_64 basado en Linux. almacén debe ser una conexión al daemon, que opera en el almacén (see El almacén).

De manera similar, es posible calcular una derivación que construye de forma cruzada un paquete para otro sistema:

Procedimiento: package-derivation almacén paquete [sistema]

Devuelve el objeto <derivation> de paquete compilado de forma cruzada desde sistema a plataforma.

plataforma debe ser una tripleta GNU válida que identifique al hardware y el sistema operativo deseado, como por ejemplo "aarch64-linux-gnu" (see Specifying Target Triplets in Autoconf).

Una vez tenga sus definiciones de paquetes puede definir facilmente variantes de dichos paquetes. See Definición de variantes de paquetes para obtener más información sobre ello.

• Referencia de package
• Referencia de origin