1.1 Gestión de software con Guix

Guix provides a command-line package management interface (see Gestión de paquetes), tools to help with software development (see Desarrollo), command-line utilities for more advanced usage (see Utilidades), as well as Scheme programming interfaces (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 Seguimiento de errores y parches). 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 Seguimiento de errores y parches). 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

Esta sección describe cómo instalar Guix en un sistema arbitrario desde un archivador autocontenido que proporciona los binarios para Guix y todas sus dependencias. Esto es normalmente más rápido que una instalación desde las fuentes, la cual es descrita en las siguientes secciones. El único requisito es tener GNU tar y Xz.

Nota: Le recomendamos el uso de este guión de instalación. Automatiza la descarga, instalación y los pasos iniciales de configuración descritos a continuación. Debe ser ejecutarse como root. Mediante el uso de dicha cuenta puede ejecutar esto:

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

If you’re running Debian or a derivative such as Ubuntu, you can instead install the package (it might be a version older than 1.4.0 but you can update it afterwards by running ‘guix pull’):

sudo apt install guix

Likewise on openSUSE:

sudo zypper install guix

Cuando haya terminado, see Configuración de la aplicación para obtener información adicional que pueda necesitar, ¡y Empezando para sus primeros pasos!

La instalación consiste más o menos en los siguientes pasos:

1. Descargue el archivador con los binarios de ‘https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz’, donde, por ejemplo, x86_64-linux puede sustituirse por i686-linux para una máquina i686 (32 bits) que ejecute el núcleo Linux (see Distribución GNU).

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

   $ wget https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz.sig
   $ gpg --verify guix-binary-1.4.0.x86_64-linux.tar.xz.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.

2. Ahora necesita convertirse en la usuaria root. Dependiendo de su distribución, puede que tenga que ejecutar su - o sudo -i. Como root, ejecute:

   # cd /tmp
   # tar --warning=no-timestamp -xf \
        /ruta/a/guix-binary-1.4.0.x86_64-linux.tar.xz
   # mv var/guix /var/ && mv gnu /
   

   Esto crea /gnu/store (see El almacén) y /var/guix. El último contiene un perfil listo para usar para root (véase el siguiente paso).

   No extraiga el archivador en un sistema Guix ya funcionando ya que sobreescribiría sus propios archivos esenciales.

   La opción --warning=no-timestamp asegura que GNU tar no emite avisos sobre “marcas de tiempo imposibles” (dichos avisos eran emitidos por GNU tar 1.26 y anteriores; las versiones recientes están bien). Parten del hecho de que todos los archivos en el archivador tienen su tiempo de modificación con valor uno (que significa el 1 de enero de 1970). Esto se hace de manera voluntaria para asegurarse de que el contenido del archivador es independiente de su fecha de creación, haciendolo por tanto reproducible.

3. Ponga disponible el perfil en ~root/.config/guix/current, que es donde guix pull instalará las actualizaciones (see Invocación de guix pull):

   # mkdir -p ~root/.config/guix
   # ln -sf /var/guix/profiles/per-user/root/current-guix \
            ~root/.config/guix/current
   

   Cargue etc/profile para aumentar PATH y otras variables de entorno relevantes:

   # GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
     source $GUIX_PROFILE/etc/profile
   

4. Cree el grupo y las cuentas de usuaria para las usuarias de construcción como se explica a continuación (see Configuración del entorno de construcción).
5. Ejecute el daemon, y configure su inicio automático durante el arranque.

   Si su distribución anfitriona usa el sistema de inicio systemd, puede hacerlo con las siguientes órdenes:

   # cp ~root/.config/guix/current/lib/systemd/system/gnu-store.mount \
        ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
        /etc/systemd/system/
   # systemctl enable --now gnu-store.mount guix-daemon
   

   You may also want to arrange for guix gc to run periodically:

   # cp ~root/.config/guix/current/lib/systemd/system/guix-gc.service \
        ~root/.config/guix/current/lib/systemd/system/guix-gc.timer \
        /etc/systemd/system/
   # systemctl enable --now guix-gc.timer
   

   You may want to edit guix-gc.service to adjust the command line options to fit your needs (see Invocación de guix gc).

   Si su distribución anfitriona usa el sistema de inicio Upstart:

   # initctl reload-configuration
   # cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \
        /etc/init/
   # start guix-daemon
   

   En otro caso, todavía puede iniciar el daemon manualmente con:

   # ~root/.config/guix/current/bin/guix-daemon \
          --build-users-group=guixbuild
   

6. Haga accesible la orden guix a otras usuarias de la máquina, por ejemplo con:

   # mkdir -p /usr/local/bin
   # cd /usr/local/bin
   # ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix
   

   Es también una buena idea poner disponible la versión Info de este manual ahí:

   # mkdir -p /usr/local/share/info
   # cd /usr/local/share/info
   # for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ;
     do ln -s $i ; done
   

   De este modo, asumiendo que /usr/local/share/info está en la ruta de búsqueda, ejecutar info guix.es abrirá este manual (see Other Info Directories in GNU Texinfo, para más detalles sobre cómo cambiar la ruta de búsqueda de Info).

7. To use substitutes from ci.guix.gnu.org, bordeaux.guix.gnu.org or a mirror (see Sustituciones), authorize them:

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

   Nota: If you do not enable substitutes, Guix will end up building everything from source on your machine, making each installation and upgrade very expensive. See Sobre la confianza en binarios, for a discussion of reasons why one might want do disable substitutes.

8. Cada usuaria puede necesitar dar algunos pasos adicionales para preparar su entorno de Guix para el uso diario, see Configuración de la aplicación.

Voilà, ¡la instalación está completa!

Puede confirmar que Guix está funcionando instalando un paquete de ejemplo en su perfil de root:

# guix install hello

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.

2.2 Requisitos

Esta sección enumera los requisitos para construir Guix desde las fuentes. El procedimiento de construcción de Guix es el mismo que el de otro software GNU, y no está cubierto aquí. Por favor, eche un vistazo a los archivos README y INSTALL en el árbol de fuentes de Guix para obtener detalles adicionales.

GNU Guix está disponible para descarga desde su sitio web en http://www.gnu.org/software/guix/.

GNU Guix depende de los siguientes paquetes:

• GNU Guile, version 3.0.x, version 3.0.3 or later;
• Guile-Gcrypt, versión 0.1.0 o posterior;
• Guile-GnuTLS (see how to install the GnuTLS bindings for Guile in GnuTLS-Guile)⁵;
• Guile-SQLite3, versión 0.1.0 o posterior;
• Guile-zlib, version 0.1.0 or later;
• Guile-lzlib;
• Guile-Avahi;
• Guile-Git, version 0.5.0 or later;
• Guile-JSON 4.3.0 o posterior;
• GNU Make.

Las siguientes dependencias son opcionales:

• La delegación de construcciones (see Uso de la facilidad de delegación de trabajo) y guix copy (see Invocación de guix copy) dependen de Guile-SSH, versión 0.13.0 o posterior.
• Guile-zstd, for zstd compression and decompression in guix publish and for substitutes (see Invocación de guix publish).
• Guile-Semver for the crate importer (see Invocación de guix import).
• Guile-Lib for the go importer (see Invocación de guix import) and for some of the “updaters” (see Invocación de guix refresh).
• Cuando libbz2 está disponible, guix daemon puede usarla para comprimir los registros de construcción.

Si no se ha proporcionado --disable-daemon a configure, los siguientes paquetes también son necesarios:

• GNU libgcrypt;
• SQLite 3;
• g++ de GCC, con implementación del estándar C++11

Cuando se configura Guix en un sistema que ya tiene una instalación de Guix, asegúrese de especificar el mismo directorio de estado que el de la instalación existente usando la opción --localstatedir al guión configure (see localstatedir in GNU Coding Standards). Habitualmente, esta opción localstatedir tiene el valor /var. El guión configure le proteje ante una mala configuración no deseada de localstatedir de modo que no pueda corromper inadvertidamente su almacén (see El almacén).

2.3 Ejecución de la batería de pruebas

Después de una ejecución exitosa de configure y make, es una buena idea ejecutar la batería de pruebas. Puede ayudar a encontrar problemas con la configuración o el entorno, o errores en el mismo Guix—e informar de fallos en las pruebas es realmente una buena forma de ayudar a mejorar el software. Para ejecutar la batería de pruebas, teclee:

make check

Los casos de prueba pueden ejecutarse en paralelo: puede usar la opción -j de GNU make para acelerar las cosas. La primera ejecución puede tomar algunos minutos en una máquina reciente; las siguientes ejecuciones serán más rápidas puesto que el almacén creado para las pruebas ya tendrá varias cosas en la caché.

También es posible ejecutar un subconjunto de las pruebas definiendo la variable de makefile TESTS como en el ejemplo:

make check TESTS="tests/store.scm tests/cpio.scm"

Por defecto, los resultados de las pruebas se muestran a nivel de archivo. Para ver los detalles de cada caso de prueba individual, es posible definir la variable de makefile SCM_LOG_DRIVER_FLAGS como en el ejemplo:

make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"

The underlying SRFI 64 custom Automake test driver used for the ’check’ test suite (located at build-aux/test-driver.scm) also allows selecting which test cases to run at a finer level, via its --select and --exclude options. Here’s an example, to run all the test cases from the tests/packages.scm test file whose names start with “transaction-upgrade-entry”:

export SCM_LOG_DRIVER_FLAGS="--select=^transaction-upgrade-entry"
make check TESTS="tests/packages.scm"

Those wishing to inspect the results of failed tests directly from the command line can add the --errors-only=yes option to the SCM_LOG_DRIVER_FLAGS makefile variable and set the VERBOSE Automake makefile variable, as in:

make check SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1

The --show-duration=yes option can be used to print the duration of the individual test cases, when used in combination with --brief=no:

make check SCM_LOG_DRIVER_FLAGS="--brief=no --show-duration=yes"

See Parallel Test Harness in GNU Automake for more information about the Automake Parallel Test Harness.

En caso de fallo, le rogamos que envíe un correo a bug-guix@gnu.org y adjunte el archivo test-suite.log. Por favor, especifique la versión de Guix usada así como los números de versión de las dependencias (see Requisitos) en su mensaje.

Guix también viene como una batería de pruebas del sistema completo que prueban instancias completas del sistema Guix. Se puede ejecutar únicamente en sistemas donde Guix ya está instalado, usando:

make check-system

o, de nuevo, definiendo TESTS para seleccionar un subconjunto de las pruebas a ejecutar:

make check-system TESTS="basic mcron"

Estas pruebas de sistema están definidas en los módulos (gnu tests …). Funcionan ejecutando el sistema operativo con una instrumentación ligera en una máquina virtual (VM). Pueden ser computacionalmente intensivas o bastante baratas, dependiendo de si hay sustituciones disponibles para sus dependencias (see Sustituciones). Algunas requieren mucho espacio de almacenamiento para alojar las imágenes de la máquina virtual.

De nuevo, en caso de fallos en las pruebas, le rogamos que envíe a bug-guix@gnu.org todos los detalles.

2.4 Preparación del daemon

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.

Las siguientes secciones explican cómo preparar el entorno del daemon de construcción. Véase también Sustituciones, para información sobre cómo permitir al daemon descargar binarios pre-construidos.

• 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 etc/guix-daemon.cil

ps -Zax | grep guix-daemon

2.5 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://ci.guix.gnu.org https://bordeaux.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.

El valor predeterminado es 0, que desactiva los plazos.

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.

El valor predeterminado es 0, que desactiva los plazos.

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

No obstante, antes de que proceda con la instalación, sea consciente de las siguientes limitaciones apreciables que se conocen en la versión 1.4.0:

• Se proporcionan más y más servicios del sistema (see Servicios), pero pueden faltar algunos.
• Están disponibles GNOME, Xfce, LXDE y Enlightenment (see Servicios de escritorio), así como un número de gestores de ventanas X11. No obstante, actualmente falta KDE.

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-1.4.0.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-1.4.0.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-1.4.0.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-1.4.0.x86_64-linux.iso of=/dev/sdX
sync

growisofs -dvd-compat -Z /dev/srX=guix-system-install-1.4.0.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 --type luks2 --pbkdf pbkdf2 /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

¡Éxito! ¡Ha arrancado en el sistema Guix! De ahora en adelante, puede actualizar el sistema cuando quiera mediante la ejecución de, digamos:

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

Esto construye una nueva generación del sistema con los últimos paquetes y servicios (see Invoking guix system). Recomendamos realizarlo de manera regular de modo que su sistema incluya las últimas actualizaciones de seguridad (see Actualizaciones de seguridad).

Nota: Tenga en cuenta que sudo guix ejecuta el ejecutable guix de su usuaria y no el de root, ya que sudo no altera PATH. Para ejecutar explícitamente el ejecutable guix de root, escriba sudo -i guix ….

The difference matters here, because guix pull updates the guix command and package definitions only for the user it is run as. This means that if you choose to use guix system reconfigure in root’s login shell, you’ll need to guix pull separately.

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,file=guix-system-install-1.4.0.sistema.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.

4.1 Chrooting into an existing system

This section details how to chroot to an already installed Guix System with the aim of reconfiguring it, for example to fix a broken GRUB installation. The process is similar to how it would be done on other GNU/Linux systems, but there are some Guix System particularities such as the daemon and profiles that make it worthy of explaining here.

1. Obtain a bootable image of Guix System. It is recommended the latest development snapshot so the kernel and the tools used are at least as as new as those of your installed system; it can be retrieved from the https://ci.guix.gnu.org URL. Follow the see Instalación desde memoria USB y DVD section for copying it to a bootable media.
2. Boot the image, and proceed with the graphical text-based installer until your network is configured. Alternatively, you could configure the network manually by following the manual-installation-networking section. If you get the error ‘RTNETLINK answers: Operation not possible due to RF-kill’, try ‘rfkill list’ followed by ‘rfkill unblock 0’, where ‘0’ is your device identifier (ID).
3. Switch to a virtual console (tty) if you haven’t already by pressing simultaneously the Control + Alt + F4 keys. Mount your file system at /mnt. Assuming your root partition is /dev/sda2, you would do:

   mount /dev/sda2 /mnt
   

4. Mount special block devices and Linux-specific directories:

   mount --bind /proc /mnt/proc
   mount --bind /sys /mnt/sys
   mount --bind /dev /mnt/dev
   

   If your system is EFI-based, you must also mount the ESP partition. Assuming it is /dev/sda1, you can do so with:

   mount /dev/sda1 /mnt/boot/efi
   

5. Enter your system via chroot:

   chroot /mnt /bin/sh
   

6. Source the system profile as well as your user profile to setup the environment, where user is the user name used for the Guix System you are attempting to repair:

   source /var/guix/profiles/system/profile/etc/profile
   source /home/user/.guix-profile/etc/profile
   

   To ensure you are working with the Guix revision you normally would as your normal user, also source your current Guix profile:

   source /home/user/.config/guix/current/etc/profile
   

7. Start a minimal guix-daemon in the background:

   guix-daemon --build-users-group=guixbuild --disable-chroot &
   

8. Edit your Guix System configuration if needed, then reconfigure with:

   guix system reconfigure your-config.scm
   

9. Finally, you should be good to reboot the system to test your fix.

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

Además, cualquier transacción de paquetes puede ser vuelta atrás. Si, por ejemplo, una actualización instala una nueva versión de un paquete que resulta tener un error importante, las usuarias pueden volver a la instancia previa de su perfil, de la cual se tiene constancia que funcionaba bien. De igual modo, la configuración global del sistema en Guix está sujeta a actualizaciones transaccionales y vuelta atrás (see Uso de la configuración del sistema).

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.

6.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 debe ser una expresión Scheme que evalúe a un objeto <package>. Esta opción es notablemente útil para diferenciar entre variantes con el mismo nombre de paquete, con expresiones como (@ (gnu packages base) 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": "https://example.com/greeter-1.0.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).

6.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/ci.guix.gnu.org.pub
# guix archive --authorize < prefix/share/guix/bordeaux.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"

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

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

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

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

Específicamente, guix pull descarga código de los canales (see Canales) especificados en una de las posibilidades siguientes, en este orden:

1. la opción --channels;
2. el archivo ~/.config/guix/channels.scm de la usuaria;
3. el archivo /etc/guix/channels.scm común al sistema;
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. Por tanto, asegúrese de añadirlo al inicio de sus rutas de búsqueda de modo que use la última versión, de modo similar para el manual Info(see Documentación).

export PATH="$HOME/.config/guix/current/bin:$PATH"
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"

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.

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

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

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.

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.

As for guix pull, the absence of any options means that the latest commit on the master branch will be used. The command

guix time-machine -- build hello

construirá el paquete hello como esté definido en la rama master, que en general es la última revisión de Guix que haya instalado. ¡Los viajes temporales funcionan en ambas direcciones!

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

6.8 Inferiores

Nota: La funcionalidad descrita aquí es una “versión de evaluación tecnológica” en la versión 1.4.0. 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 Scheme: 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 Scheme: 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 Scheme: inferior-packages inferior

Devuelve la lista de paquetes conocida por inferior.

Procedimiento Scheme: 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 Scheme: inferior-package? obj

Devuelve verdadero si obj es un paquete inferior.

Procedimiento Scheme: inferior-package-name paquete

Procedimiento Scheme: inferior-package-version paquete

Procedimiento Scheme: inferior-package-synopsis paquete

Procedimiento Scheme: inferior-package-description paquete

Procedimiento Scheme: inferior-package-home-page paquete

Procedimiento Scheme: inferior-package-location paquete

Procedimiento Scheme: inferior-package-inputs paquete

Procedimiento Scheme: inferior-package-native-inputs paquete

Procedimiento Scheme: inferior-package-propagated-inputs paquete

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

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

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

Procedimiento Scheme: 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.

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

6.10 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 ci.guix.gnu.org to /tmp/emacs:

$ wget -O - \
  https://ci.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://ci.guix.gnu.org/nar/lzip/…-emacs-26.3 \
  | lzip -d | guix archive -t

7.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-personal-packages channel (see Invocación de guix describe).

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

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

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

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

7.6 Creación de un canal

Digamos que tiene un montón de variaciones personalizadas de paquetes que piensa que no tiene mucho sentido contribuir al proyecto Guix, pero quiere tener esos paquetes disponibles en su línea de órdenes de manera transparente. Primero debería escribir módulos que contengan esas definiciones de paquete (see Módulos de paquetes), mantenerlos en un repositorio Git, y de esta manera usted y cualquier otra persona podría usarlos como un canal adicional del que obtener paquetes. Limpio, ¿no?

Aviso: Antes de que, querida usuaria, grite—“¡Guau, esto es la caña!”—y publique su canal personal al mundo, nos gustaría compartir algunas palabras de precaución:

• 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.
• Cuando mantiene definiciones de paquete fuera de Guix, nosotras, las desarrolladoras de Guix, consideramos que la carga de la compatibilidad cae de su lado. Recuerde que los módulos y definiciones de paquetes son solo código Scheme que usa varias interfaces programáticas (APIs). Queremos mantener la libertad de cambiar dichas interfaces para seguir mejorando Guix, posiblemente en formas que pueden romper su canal. Nunca cambiamos las interfaces gratuitamente, pero no vamos tampoco a congelar las interfaces.
• 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.

Para crear un canal, cree un repositorio Git que contenga sus propios módulos de paquetes y haga que esté disponible. El repositorio puede contener cualquier cosa, pero un canal útil contendrá módulos Guile que exportan paquetes. Una vez comience a usar un canal, Guix se comportará como si el directorio raíz del repositorio Git de dicho canal hubiese sido añadido a la ruta de carga de Guile (see Load Paths in GNU Guile Reference Manual). Por ejemplo, si su canal contiene un archivo en mis-paquetes/mis-herramientas.scm que define un módulo, entonces dicho módulo estará disponible bajo el nombre (mis-paquetes mis-herramientas), y podrá usarlo como cualquier otro módulo (see Modules in GNU Guile Reference Manual).

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.

7.7 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"))

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

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

Antes de que suba los cambios a su repositorio Git público puede ejecutar guix git-authenticate para verificar que ha firmado todas las revisiones que va a subir con una clave autorizada:

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.

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

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

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

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, this time sharing network access with the host and preserving its DISPLAY environment variable, but without even sharing the current directory:

guix shell --container --network --no-cwd ungoogled-chromium \
  --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.64 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.

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

8.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.64 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).

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

donde archivo es la imagen devuelta por guix pack, y guile-guile-readline es la “etiqueta de imagen”. Véase la documentación de Docker para más información.

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

Produce un archivador que sigue la especificación de imágenes Docker. El “nombre de repositorio” como aparece en la salida de la orden docker images se calcula a partir de los nombres de paquete proporcionados en la línea de órdenes o en el archivo de manifiesto.

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.

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.

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

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

8.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).

8.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…]

De manera predeterminada esta orden verifica la copia de trabajo de Git en el directorio actual; no muestra nada y termina con un código de salida cero en caso satisfactorio y con un valor distinto a cero en caso de fallo. revisión denota la primera revisión a partir de la cual la verificación tiene lugar, y firma es la huella de OpenPGP de la clave pública usada para firmar revisión. Juntas forman la “presentación del canal” (see presentación del canal). Las siguientes opciones le permiten controlar con más detalle el proceso.

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

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

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

9.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 Scheme: 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 Scheme: package-cross-derivation almacén paquete plataforma [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