Manual de referencia de GNU Guix

Table of Contents

Next: , Up: (dir)   [Contents][Index]

GNU Guix

Este documento describe GNU Guix versión df72ba9, una herramienta funcional de gestión de paquetes escrita para el sistema GNU.

This manual is also available in Simplified Chinese (see GNU Guix参考手册), French (see Manuel de référence de GNU Guix), German (see Referenzhandbuch zu GNU Guix), Spanish (see Manual de referencia de GNU Guix), and Russian (see Руководство GNU Guix). If you would like to translate it in your native language, consider joining Weblate (see Traduciendo Guix).


Next: , Previous: , Up: Top   [Contents][Index]

1 Introducción

GNU Guix1 es una herramienta de gestión de paquetes y una distribución del sistema GNU. Guix facilita a usuarias sin privilegios la instalación, actualización o borrado de paquetes de software, la vuelta a un conjunto de paquetes previo atómicamente, la construcción de paquetes desde las fuentes, y ayuda de forma general en la creación y mantenimiento de entornos software.

Puede instalar GNU Guix sobre un sistema GNU/Linux existente, donde complementará las herramientas disponibles sin interferencias (see Instalación), o puede usarse como un sistema operativo en sí mismo, el sistema Guix2. See Distribución GNU.


Next: , Up: Introducción   [Contents][Index]

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


Previous: , Up: Introducción   [Contents][Index]

1.2 Distribución GNU

Guix viene con una distribución del sistema GNU consistente en su totalidad de software libre3. 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 playform 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 Introducción 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.

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.


Next: , Previous: , Up: Top   [Contents][Index]

2 Instalación

Nota: Recomendamos el uso de este guión de instalación para instalar Guix sobre un sistema GNU/Linux en ejecución, de aquí en adelante referido como una distribución distinta.4 El guión automatiza la descarga, instalación y configuración inicial de Guix. Debe ejecutarse como la usuaria de administración root.

Cuando está instalado sobre una distribución distinta, GNU Guix complementa las herramientas disponibles sin interferencias. Sus datos radican exclusivamente en dos directorios, normalmente /gnu/store y /var/guix; otros archivos en su sistema, como /etc, permanecen intactos.

Una vez instalado, Guix puede ser actualizado ejecutando guix pull (see Invocación de guix pull.

Si prefiere realizar los pasos de instalación manualmente o desea personalizarlos, puede encontrar útiles las siguientes instrucciones. Describen los requisitos de software de Guix, así como su instalación manual y la preparación para su uso.


Next: , Up: Instalación   [Contents][Index]

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

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-df72ba9.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-df72ba9.x86_64-linux.tar.xz.sig
    $ gpg --verify guix-binary-df72ba9.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=127547' \
          -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-df72ba9.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.


Next: , Previous: , Up: Instalación   [Contents][Index]

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:

Las siguientes dependencias son opcionales:

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

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


Next: , Previous: , Up: Instalación   [Contents][Index]

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.


Next: , Previous: , Up: Instalación   [Contents][Index]

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.


Next: , Up: Preparación del daemon   [Contents][Index]

2.4.1 Configuración del entorno de construcción

En una configuración multiusuaria estándar, Guix y su daemon—el programa guix-daemon—son instalados por la administradora del sistema; /gnu/store pertenece a root y guix-daemon se ejecuta como root. Usuarias sin privilegios pueden usar las herramientas de Guix para construir paquetes o acceder al almacén de otro modo, y el daemon lo hará en delegación suya, asegurando que el almacén permanece en un estado consistente, y permitiendo compartir entre usuarias los paquetes construidos.

Mientras que guix-daemon se ejecuta como root, puede que no desee que los procesos de construcción de paquetes se ejecuten como root también, por razones de seguridad obvias. Para evitarlo, una reserva especial de usuarias de construcción debe ser creada para ser usada por los procesos de construcción iniciados por el daemon. Estas usuarias de construcción no necesitan tener un intérprete ni un directorio home: simplemente serán usadas cuando el daemon se deshaga de los privilegios de root en los procesos de construcción. Tener varias de dichas usuarias permite al daemon lanzar distintos procesos de construcción bajo UID separados, lo que garantiza que no interferirán entre ellos—una característica esencial ya que las construcciones se caracterizan como funciones puras (see Introducción).

En un sistema GNU/Linux, una reserva de usuarias de construcción puede ser creada así (usando la sintaxis de Bash y las órdenes de shadow):

# 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

El número de usuarias de construcción determina cuantos trabajos de construcción se pueden ejecutar en paralelo, especificado por la opción --max-jobs (see --max-jobs). Para usar guix system vm y las órdenes relacionadas, puede necesitar añadir las usuarias de construcción al grupo kvm para que puedan acceder a /dev/kvm, usando -G guixbuild,kvm en vez de -G guixbuild (see Invocación de guix system).

El programa guix-daemon puede ser ejecutado entonces como root con la siguiente orden5:

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

De este modo, el daemon inicia los procesos de construcción en un “chroot”, bajo una de las usuarias guixbuilder. En GNU/Linux, por defecto, el entorno “chroot” contiene únicamente:

The chroot does not contain a /home directory, and the HOME environment variable is set to the non-existent /homeless-shelter. This helps to highlight inappropriate uses of HOME in the build scripts of packages.

Puede influir en el directorio que el daemon utiliza para almacenar los árboles de construcción a través de la variable de entorno TMPDIR. No obstante, el árbol de construcción en el “chroot” siempre se llama /tmp/guix-build-nombre.drv-0, donde nombre es el nombre de la derivación—por ejemplo, coreutils-8.24. De este modo, el valor de TMPDIR no se escapa a los entornos de construcción, lo que evita discrepancias en caso de que los procesos de construcción capturen el nombre de su árbol de construcción.

El daemon también respeta la variable de entorno http_proxy y https_proxy para las descargas HTTP y HTTPS que realiza, ya sea para derivaciones de salida fija (see Derivaciones) o para sustituciones (see Sustituciones).

Si está instalando Guix como una usuaria sin privilegios, es posible todavía ejecutar guix-daemon siempre que proporcione el parámetro --disable-chroot. No obstante, los procesos de construcción no estarán aislados entre sí ni del resto del sistema. Por tanto, los procesos de construcción pueden interferir entre ellos y pueden acceder a programas, bibliotecas y otros archivos disponibles en el sistema—haciendo mucho más difícil verlos como funciones puras.


Next: , Previous: , Up: Preparación del daemon   [Contents][Index]

2.4.2 Uso de la facilidad de delegación de trabajo

Cuando así se desee, el daemon de construcción puede delegar construcciones de derivación a otras máquinas ejecutando Guix, usando el procedimiento de extensión de construcción offload7. Cuando dicha característica es activada se lee una lista de máquinas de construcción especificadas por la usuaria desde /etc/guix/machines.scm; cada vez que se solicita una construcción, por ejemplo via guix build, el daemon intenta su delegación a una de las máquinas que satisfaga las condiciones de la derivación, en particular su tipo de sistema—por ejemplo, x86_64-linux. Una única máquina puede usarse para múltiples tipos de sistema, ya sea porque los implemente su arquitectura de manera nativa, a través de emulación (see Transparent Emulation with QEMU), o ambas. Los prerrequisitos restantes para la construcción se copian a través de SSH a la máquina seleccionada, la cual procede con la construcción; con un resultado satisfactorio la o las salidas de la construcción son copiadas de vuelta a la máquina inicial. La facilidad de descarga de trabajo incorpora una planificación básica que intenta seleccionar la mejor máquina, la cual es seleccionada entre las máquinas disponibles en base a criterios como los siguientes:

  1. La disponibilidad de un puesto de construcción. Una máquina de construcción tiene el número de puestos de construcción (conexiones) que indique el valor de parallel-builds en su objeto build-machine.
  2. Su velocidad relativa, a través del campo speed de su objeto build-machine.
  3. Su carga de trabajo. El valor normalizado de carga debe ser menor aun valor límite, configurable a través del campo overload-threshold de su objeto build-machine.
  4. El espacio disponible en el disco. Debe haber más de 100 MiB disponibles.

El archivo /etc/guix/machines.scm normalmente tiene un contenido de este estilo:

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

En el ejemplo anterior se especifica una lista de dos máquinas de construcción, una para las arquitecturas x86_64 y i686, y otra para la arquitectura aarch64.

De hecho, este archivo es—¡sin sorpresa ninguna!—un archivo Scheme que se evalúa cuando el procedimiento de extensión offload se inicia. El valor que devuelve debe ser una lista de objetos build-machine. Mientras que este ejemplo muestra una lista fija de máquinas de construcción, una puede imaginarse, digamos, el uso de DNS-SD para devolver una lista de máquinas de construcción potenciales descubierta en la red local (see Guile-Avahi in Using Avahi in Guile Scheme Programs). El tipo de datos build-machine se detalla a continuación.

Tipo de datos: build-machine

Este tipo de datos representa las máquinas de construcción a las cuales el daemon puede delegar construcciones. Los campos importantes son:

name

El nombre de red de la máquina remota.

systems

Los tipos de sistema implementados por la máquina remota—por ejemplo, (list "x86_64-linux" "i686-linux").

user

La cuenta de usuaria usada para la conexión a la máquina remota por SSH. Tenga en cuenta que el par de claves SSH no debe estar protegido por contraseña, para permitir ingresos al sistema no interactivos.

host-key

Este campo debe contener la clave pública de la máquina de SSH en formato OpenSSH. Es usado para autentificar la máquina cuando nos conectamos a ella. Es una cadena larga más o menos así:

ssh-ed25519 AAAAC3NzaC…mde+UhL recordatorio@example.org

Si la máquina está ejecutando el daemon OpenSSH, sshd, la clave pública de la máquina puede encontrarse en un archivo como /etc/ssh/ssh_host_ed25519_key.pub.

Si la máquina está ejecutando el daemon SSH GNU lsh, lshd, la clave de la máquina está en /etc/lsh/host-key.pub o un archivo similar. Puede convertirse a formato OpenSSH usando lsh-export-key (see Converting keys in LSH Manual):

$ lsh-export-key --openssh < /etc/lsh/host-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV…

Ciertos número de campos opcionales pueden ser especificados:

port (predeterminado: 22)

Número de puerto del servidor SSH en la máquina.

private-key (predeterminada: ~root/.ssh/id_rsa)

El archivo de clave privada SSH usado para conectarse a la máquina, en formato OpenSSH. Esta clave no debe estar protegida con una contraseña.

Tenga en cuenta que el valor predeterminado es la clave privada de la cuenta de root. Asegúrese de que existe si usa el valor predeterminado.

compression (predeterminado: "zlib@openssh.com,zlib")
compression-level (predeterminado: 3)

Los métodos de compresión y nivel de compresión a nivel SSH solicitados.

Tenga en cuenta que la delegación de carga depende de la compresión SSH para reducir el ancho de banda usado cuando se transfieren archivos hacia y desde máquinas de construcción.

daemon-socket (predeterminado: "/var/guix/daemon-socket/socket")

Nombre de archivo del socket de dominio Unix en el que guix-daemon escucha en esa máquina.

overload-threshold (predeterminado: 0.6)

El límite superior de carga, el cual se usa en la planificación de delegación de tareas para descartar potenciales máquinas si superan dicho límite. Dicho valor más o menos representa el uso del procesador de la máquina, con un rango de 0.0 (0%) a 1.0 (100%). También se puede desactivar si se proporciona el valor #f en overload-threshold.

parallel-builds (predeterminadas: 1)

El número de construcciones que pueden ejecutarse en paralelo en la máquina.

speed (predeterminado: 1.0)

Un “factor de velocidad relativa”. El planificador de delegaciones tenderá a preferir máquinas con un factor de velocidad mayor.

features (predeterminadas: '())

Una lista de cadenas denotando las características específicas permitidas por la máquina. Un ejemplo es "kvm" para máquinas que tienen los módulos KVM de Linux y las correspondientes características hardware. Las derivaciones pueden solicitar las características por nombre, y entonces se planificarán en las máquinas adecuadas.

El ejecutable guix debe estar en la ruta de búsqueda de las máquinas de construcción. Puede comprobar si es el caso ejecutando:

ssh build-machine guix repl --version

Hay una última cosa por hacer una vez machines.scm está en su lugar. Como se ha explicado anteriormente, cuando se delega, los archivos se transfieren en ambas direcciones entre los almacenes de las máquinas. Para que esto funcione, primero debe generar un par de claves en cada máquina para permitir al daemon exportar los archivos firmados de archivos en el almacén (see Invocación de guix archive):

# guix archive --generate-key

Cada máquina de construcción debe autorizar a la clave de la máquina maestra para que acepte elementos del almacén que reciba de la maestra:

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

La máquina maestra debe autorizar la clave de cada máquina de construcción de la misma manera.

Todo este lío con claves está ahí para expresar las mutuas relaciones de confianza entre pares de la máquina maestra y las máquinas de construcción. Concretamente, cuando la maestra recibe archivos de una máquina de construcción (y vice versa), su daemon de construcción puede asegurarse de que son genuinos, no han sido modificados, y que están firmados por una clave autorizada.

Para comprobar si su configuración es operacional, ejecute esta orden en el nodo maestro:

# guix offload test

This will attempt to connect to each of the build machines specified in /etc/guix/machines.scm, make sure Guix is available on each machine, attempt to export to the machine and import from it, and report any error in the process.

Si quiere probar un archivo de máquinas diferente, simplemente lo debe especificar en la línea de órdenes:

# guix offload test otras-maquinas.scm

Por último, puede probar un subconjunto de máquinas cuyos nombres coincidan con una expresión regular así:

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

Para mostrar la carga actual de todas las máquinas de construcción, ejecute esta orden en el nodo principal:

# guix offload status

Previous: , Up: Preparación del daemon   [Contents][Index]

2.4.3 Soporte de SELinux

Guix incluye un archivo de política SELinux en etc/guix-daemon.cil que puede ser instalado en un sistema donde SELinux está activado, para etiquetar los archivos Guix y especificar el comportamiento esperado del daemon. Ya que el sistema Guix no proporciona una política base de SELinux, la política del daemon no puede usarse en el sistema Guix.

2.4.3.1 Instalación de la política de SELinux

Para instalar la política ejecute esta orden como root:

semodule -i etc/guix-daemon.cil

Una vez hecho, vuelva a etiquetar el sistema de archivos con restorecon o con un mecanismo distinto que proporcione su sistema.

Una vez la política está instalada, el sistema de archivos ha sido re-etiquetado, y el daemon ha sido reiniciado, debería ejecutarse en el contexto guix_daemon_t. Puede confirmarlo con la siguiente orden:

ps -Zax | grep guix-daemon

Monitorice los archivos de log de SELinux mientras ejecuta una orden como guix build hello para convencerse que SELinux permite todas las operaciones necesarias.

2.4.3.2 Limitaciones

Esta política no es perfecta. Aquí está una lista de limitaciones o comportamientos extraños que deben ser considerados al desplegar la política SELinux provista para el daemon Guix.

  1. guix_daemon_socket_t isn’t actually used. None of the socket operations involve contexts that have anything to do with guix_daemon_socket_t. It doesn’t hurt to have this unused label, but it would be preferable to define socket rules for only this label.
  2. guix gc no puede acceder enlaces arbitrarios a los perfiles. Por diseño, la etiqueta del archivo del destino de un enlace simbólico es independiente de la etiqueta de archivo del archivo en sí. Aunque todos los perfiles bajo $localstatedir se etiquetan, los enlaces para estos perfiles heredan la etiqueta del directorio en el que están. Para enlaces en el directorio de la usuaria esto será user_home_t. Pero para los enlaces del directorio de root, o /tmp, o del directorio del servidor HTTP, etc., esto no funcionará. guix gc se verá incapacitado para leer y seguir dichos enlaces.
  3. La característica del daemon de esperar conexiones TCP puede que no funcione más. Esto puede requerir reglas adicionales, ya que SELinux trata los sockets de red de forma diferente a los archivos.
  4. Actualmente todos los archivos con un nombre coincidente con la expresión regular /gnu/store.+-(gux-.+|profile)/bin/guix-daemon tienen asignada la etiqueta guix_daemon_exec_t; esto significa que cualquier archivo con ese nombre en cualquier perfil tendrá permitida la ejecución en el dominio guix_daemon_t. Esto no es ideal. Una atacante podría construir un paquete que proporcione este ejecutable y convencer a la usuaria para instalarlo y ejecutarlo, lo que lo eleva al dominio guix_daemon_t. Llegadas a este punto, SELinux no puede prevenir que acceda a los archivos permitidos para los procesos en dicho dominio.

    You will need to relabel the store directory after all upgrades to guix-daemon, such as after running guix pull. Assuming the store is in /gnu, you can do this with restorecon -vR /gnu, or by other means provided by your operating system.

    Podríamos generar una política mucho más restrictiva en tiempo de instalación, de modo que solo el nombre exacto del archivo del ejecutable de guix-daemon actualmente instalado sea marcado como guix_daemon_exec_t, en vez de usar una expresión regular amplia. La desventaja es que root tendría que instalar o actualizar la política en tiempo de instalación cada vez que se actualizase el paquete de Guix que proporcione el ejecutable de guix-daemon realmente en ejecución.


Next: , Previous: , Up: Instalación   [Contents][Index]

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 Configuración de delegación del daemon). 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 Configuración de delegación del daemon), 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.


Next: , Previous: , Up: Instalación   [Contents][Index]

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.

2.6.1 Localizaciones

Los paquetes instalados a través de Guix no usarán los datos de localización del sistema anfitrión. En vez de eso, debe instalar primero uno de los paquetes de localización disponibles con Guix y después definir la variable de entorno GUIX_LOCPATH:

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

Note that the glibc-locales package contains data for all the locales supported by the GNU libc and weighs in at around 930 MiB8. If you only need a few locales, you can define your custom locales package via the make-glibc-utf8-locales procedure from the (gnu packages base) module. The following example defines a package containing the various Canadian UTF-8 locales known to the GNU libc, that weighs around 14 MiB:

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

La variable GUIX_LOCPATH juega un rol similar a LOCPATH (see LOCPATH in The GNU C Library Reference Manual). No obstante, hay dos diferencias importantes:

  1. GUIX_LOCPATH es respetada únicamente por la libc dentro de Guix, y no por la libc que proporcionan las distribuciones distintas. Por tanto, usar GUIX_LOCPATH le permite asegurarse de que los programas de la distribución distinta no cargarán datos de localización incompatibles.
  2. libc añade un sufijo a cada entrada de GUIX_LOCPATH con /X.Y, donde X.Y es la versión de libc—por ejemplo, 2.22. Esto significa que, en caso que su perfil Guix contenga una mezcla de programas enlazados contra diferentes versiones de libc, cada versión de libc únicamente intentará cargar datos de localización en el formato correcto.

Esto es importante porque el formato de datos de localización usado por diferentes versiones de libc puede ser incompatible.

2.6.2 Selector de servicios de nombres

Cuando se usa Guix en una distribución distinta, recomendamos encarecidamente que el sistema ejecute el daemon de caché del servicio de nombres de la biblioteca de C de GNU, ncsd, que debe escuchar en el socket /var/run/nscd/socket. En caso de no hacerlo, las aplicaciones instaladas con Guix pueden fallar al buscar nombres de máquinas o cuentas de usuaria, o incluso pueden terminar abruptamente. Los siguientes párrafos explican por qué.

La biblioteca de C de GNU implementa un selector de servicios de nombres (NSS), que es un mecanismo extensible para “búsquedas de nombres” en general: resolución de nombres de máquinas, cuentas de usuaria y más (see Selector de servicios de nombres in The GNU C Library Reference Manual).

Al ser extensible, NSS permite el uso de módulos, los cuales proporcionan nuevas implementaciones de búsqueda de nombres: por ejemplo, el módulo nss-mdns permite la resolución de nombres de máquina .local, el módulo nis permite la búsqueda de cuentas de usuaria usando el servicio de información de red (NIS), etc. Estos “servicios de búsqueda” extra se configuran para todo el sistema en /etc/nsswitch.conf, y todos los programas en ejecución respetan esta configuración (see NSS Configuration File in The GNU C Reference Manual).

Cuando se realiza una búsqueda de nombres—por ejemplo, llamando a la función getaddrinfo en C—las aplicaciones primero intentarán conectar con nscd; en caso satisfactorio, nscd realiza la búsqueda de nombres en delegación suya. Si nscd no está ejecutándose, entonces realizan la búsqueda por ellas mismas, cargando los servicios de búsqueda de nombres en su propio espacio de direcciones y ejecutándola. Estos servicios de búsqueda de nombres—los archivos libnss_*.so—son abiertos con dlopen, pero pueden venir de la biblioteca de C del sistema, en vez de la biblioteca de C contra la que la aplicación está enlazada (la biblioteca de C que viene en Guix).

Y aquí es donde está el problema: si su aplicación está enlazada contra la biblioteca de C de Guix (digamos, glibc 2.24) e intenta cargar módulos de otra biblioteca de C (digamos, libnss_mdns.so para glibc 2.22), probablemente terminará abruptamente o sus búsquedas de nombres fallarán inesperadamente.

Ejecutar nscd en el sistema, entre otras ventajas, elimina este problema de incompatibilidad binaria porque esos archivos libnss_*.so se cargan en el proceso nscd, no en la aplicación misma.

2.6.3 Tipografías X11

The majority of graphical applications use Fontconfig to locate and load fonts and perform X11-client-side rendering. The fontconfig package in Guix looks for fonts in $HOME/.guix-profile by default. Thus, to allow graphical applications installed with Guix to display fonts, you have to install fonts with Guix as well. Essential font packages include font-ghostscript, font-dejavu, and font-gnu-freefont.

Una vez que haya instalado o borrado tipografías, o cuando se de cuenta de que una aplicación no encuentra las tipografías, puede que necesite instalar Fontconfig y forzar una actualización de su caché de tipografías ejecutando:

guix install fontconfig
fc-cache -rv

Para mostrar texto escrito en lenguas chinas, Japonés o Coreano en aplicaciones gráficas, considere instalar font-adobe-source-han-sans o font-wqy-zenhei. La anterior tiene múltiples salidas, una por familia de lengua (see Paquetes con múltiples salidas). Por ejemplo, la siguiente orden instala tipografías para lenguas chinas:

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

Programas más antiguos como xterm no usan Fontconfig sino que dependen en el lado del servidor para realizar el renderizado de tipografías. Dichos programas requieren especificar un nombre completo de tipografía usando XLFD (Descripción lógica de tipografías X), como esta:

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

Para ser capaz de usar estos nombres completos para las tipografías TrueType instaladas en su perfil Guix, necesita extender la ruta de fuentes del servidor X:

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

Después de eso, puede ejecutar xlsfonts (del paquete xlsfonts) para asegurarse que sus tipografías TrueType se enumeran aquí.

2.6.4 Certificados X.509

El paquete nss-certs proporciona certificados X.509, que permiten a los programas verificar los servidores accedidos por HTTPS.

Cuando se usa Guix en una distribución distinta, puede instalar este paquete y definir las variables de entorno relevantes de modo que los paquetes sepan dónde buscar los certificados. See Certificados X.509, para información detallada.

2.6.5 Paquetes Emacs

Cuando instale paquetes de Emacs con Guix los archivos de Elisp se encuentran en el directorio share/emacs/site-lisp/ del perfil en el que se instalen. Las bibliotecas de Elisp se ponen a disposición de Emacs a través de la variable de entorno EMACSLOADPATH, a la cual se le asigna un valor cuando se instale el propio Emacs.

De manera adicional, las definiciones de carga automática se evaluan de manera automática en la inicialización de Emacs, mediante el procedimiento guix-emacs-autoload-packages específico de Guix. Si, por alguna razón, desea evitar la carga automática de paquetes Emacs instalados con Guix, puede hacerlo ejecutando Emacs con la opción --no-site-file (see Init File in The GNU Emacs Manual).


Previous: , Up: Instalación   [Contents][Index]

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


Next: , Previous: , Up: Top   [Contents][Index]

3 Instalación del sistema

Esta sección explica cómo instalar el sistema Guix en una máquina. Guix, como gestor de paquetes, puede instalarse sobre un sistema GNU/Linux en ejecución, see Instalación.


Next: , Up: Instalación del sistema   [Contents][Index]

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

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.


Next: , Previous: , Up: Instalación del sistema   [Contents][Index]

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

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.


Next: , Previous: , Up: Instalación del sistema   [Contents][Index]

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-df72ba9.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-df72ba9.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-df72ba9.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=127547 \
      -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

Conecte una memoria USB de 1 GiB o más a su máquina, y determine su nombre de dispositivo. Asumiendo que la memoria USB es /dev/sdX copie la imagen con:

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

El acceso a /dev/sdX normalmente necesita privilegios de root.

Grabación en un DVD

Introduzca un DVD en su máquina para grabarlo, y determine el nombre del dispositivo. Asumiendo que la unidad DVD es /dev/srX, copie la imagen con:

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

El acceso a /dev/srX normalmente necesita privilegios de root.

Arranque

Once this is done, you should be able to reboot the system and boot from the USB stick or DVD. The latter usually requires you to get in the BIOS or UEFI boot menu, where you can choose to boot from the USB stick. In order to boot from Libreboot, switch to the command mode by pressing the c key and type search_grub usb.

See Instalación de Guix en una máquina virtual, si, en vez de esto, desea instalar el sistema Guix en una máquina virtual (VM).


Next: , Previous: , Up: Instalación del sistema   [Contents][Index]

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.


Next: , Previous: , Up: Instalación del sistema   [Contents][Index]

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.

configuración de red en la instalación
gráfica

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.

particionado en la instalación
gráfica

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.

retomado del proceso de instalación

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!


Next: , Previous: , Up: Instalación del sistema   [Contents][Index]

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


Next: , Up: Instalación manual   [Contents][Index]

3.6.1 Distribución de teclado, red y particionado

Antes de instalar el sistema, puede desear ajustar la distribución del teclado, configurar la red y particionar el disco duro deseado. Esta sección le guiará durante este proceso.

3.6.1.1 Distribución de teclado

La imagen de instalación usa la distribución de teclado QWERTY de los EEUU. Si desea cambiarla, puede usar la orden loadkeys. Por ejemplo, la siguiente orden selecciona la distribución de teclado para el castellano:

loadkeys es

Véanse los archivos bajo /run/current-system/profile/share/keymaps para la obtención de una lista de distribuciones de teclado disponibles. Ejecute man loadkeys para más información.

3.6.1.2 Red

Ejecute la siguiente orden para ver los nombres asignados a sus interfaces de red:

ifconfig -a

… o, usando la orden específica de GNU/Linux ip:

ip address

El nombre de las interfaces de cable comienza con ‘e’; por ejemplo, la interfaz que corresponde a la primera controladora Ethernet en la placa se llama ‘eno1’. El nombre de las interfaces inalámbricas comienza con ‘w’, como ‘w1p2s0’.

Conexión por cable

Para configurar una red por cable ejecute la siguiente orden, substituyendo interfaz con el nombre de la interfaz de cable que desea usar.

ifconfig interfaz up

… o, usando la orden específica de GNU/Linux ip:

ip link set interfaz up
Conexión sin cable

Para configurar una red inalámbrica, puede crear un archivo de configuración para la herramienta de configuración wpa_supplicant (su ruta no es importante) usando uno de los editores de texto disponibles como nano:

nano wpa_supplicant.conf

Como un ejemplo, la siguiente plantilla puede colocarse en este archivo y funcionará para muchas redes inalámbricas, siempre que se proporcione el SSID y la contraseña reales de la red a la que se va a conectar:

network={
  ssid="mi-ssid"
  key_mgmt=WPA-PSK
  psk="la contraseña de la red"
}

Inicie el servicio inalámbrico y lance su ejecución en segundo plano con la siguiente orden (sustituya interfaz por el nombre de la interfaz de red que desea usar):

wpa_supplicant -c wpa_supplicant.conf -i interfaz -B

Ejecute man wpa_supplicant para más información.

En este punto, necesita obtener una dirección IP. En una red donde las direcciones IP se asignan automáticamente mediante DHCP, puede ejecutar:

dhclient -v interfaz

Intente hacer ping a un servidor para comprobar si la red está funcionando correctamente:

ping -c 3 gnu.org

Configurar el acceso por red es casi siempre un requisito debido a que la imagen no contiene todo el software y las herramientas que puedan ser necesarias.

Si necesita que el acceso a HTTP y HTTPS se produzca a través de una pasarela (“proxy”), ejecute la siguiente orden:

herd set-http-proxy guix-daemon URL

donde URL es la URL de la pasarela, por ejemplo http://example.org:8118.

Si lo desea, puede continuar la instalación de forma remota iniciando un servidor SSH:

herd start ssh-daemon

Asegúrese de establecer una contraseña con passwd, o configure la verificación de clave pública de OpenSSH antes de ingresar al sistema.

3.6.1.3 Particionado de discos

A menos que se haya realizado previamente, el siguiente paso es el particionado, y después dar formato a la/s partición/es deseadas.

La imagen de instalación contiene varias herramientas de particionado, incluyendo Parted (see Overview in GNU Parted User Manual), fdisk y cfdisk. Invoque su ejecución y configure el mapa de particiones deseado en su disco:

cfdisk

Si su disco usa el formato de tabla de particiones GUID (GPT) y tiene pensado instalar GRUB basado en BIOS (la opción predeterminada), asegúrese de tener una partición de arranque BIOS disponible (see BIOS installation in GNU GRUB manual).

Si en vez de eso desea GRUB basado en EFI, se requiere una Partición del Sistema EFI (ESP) con formato FAT32. Esta partición puede montarse en /boot/efi y debe tener la opción esp activa. Por ejemplo, en parted:

parted /dev/sda set 1 esp on

Nota: ¿No esta segura si usar GRUB basado en EFI o en BIOS? Si el directorio /sys/firmware/efi existe en la imagen de instalación, probablemente debería realizar una instalación EFI, usando grub-efi-bootloader. En otro caso, debe usar GRUB basado en BIOS, conocido como grub-bootloader. See Configuración del gestor de arranque, para más información sobre cargadores de arranque.

Once you are done partitioning the target hard disk drive, you have to create a file system on the relevant partition(s)9. For the ESP, if you have one and assuming it is /dev/sda1, run:

mkfs.fat -F32 /dev/sda1

El formato de sistema de archivos ext4 es el formato más ampliamente usado para el sistema de archivos raíz. Otros sistemas de archivos, como por ejemplo Btrfs, implementan compresión, la cual complementa adecuadamente la deduplicación de archivos que el daemon realiza de manera independiente al sistema de archivos(see deduplicación).

Preferentemente, asigne una etiqueta a los sistemas de archivos de modo que pueda referirse a ellos de forma fácil y precisa en las declaraciones file-system (see Sistemas de archivos). Esto se consigue habitualmente con la opción -L de mkfs.ext4 y las ordenes relacionadas. Por tanto, asumiendo que la partición de la raíz es /dev/sda2, se puede crear un sistema de archivos con la etiqueta mi-raiz de esta manera:

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

If you are instead planning to encrypt the root partition, you can use the Cryptsetup/LUKS utilities to do that (see man cryptsetup for more information).

Aviso: Note that GRUB can unlock LUKS2 devices since version 2.06, but only supports the PBKDF2 key derivation function, which is not the default for cryptsetup luksFormat. You can check which key derivation function is being used by a device by running cryptsetup luksDump device, and looking for the PBKDF field of your keyslots.

Assuming you want to store the root partition on /dev/sda2, the command sequence to format it as a LUKS2 partition would be along these lines:

cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 /dev/sda2
cryptsetup open /dev/sda2 my-partition
mkfs.ext4 -L my-root /dev/mapper/my-partition

Una vez hecho esto, monte el sistema de archivos deseado bajo /mnt con una orden como (de nuevo, asumiendo que mi-raiz es la etiqueta del sistema de archivos raíz):

mount LABEL=mi-raiz /mnt

Monte también cualquier otro sistema de archivos que desee usar en el sistema resultante relativamente a esta ruta. Si ha optado por /boot/efi como el punto de montaje de EFI, por ejemplo, ahora debe ser montada en /mnt/boot/efi para que guix system init pueda encontrarla más adelante.

Finally, if you plan to use one or more swap partitions (see Swap Space), make sure to initialize them with mkswap. Assuming you have one swap partition on /dev/sda3, you would run:

mkswap /dev/sda3
swapon /dev/sda3

De manera alternativa, puede usar un archivo de intercambio. Por ejemplo, asumiendo que en el nuevo sistema desea usar el archivo /archivo-de-intercambio como tal, ejecutaría10:

# 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

Fíjese que si ha cifrado la partición raíz y creado un archivo de intercambio en su sistema de archivos como se ha descrito anteriormente, el cifrado también protege al archivo de intercambio, como a cualquier archivo en dicho sistema de archivos.


Previous: , Up: Instalación manual   [Contents][Index]

3.6.2 Procedimiento de instalación

Con las particiones deseadas listas y la raíz deseada montada en /mnt, estamos preparadas para empezar. Primero, ejecute:

herd start cow-store /mnt

Esto activa la copia-durante-escritura en /gnu/store, de modo que los paquetes que se añadan durante la fase de instalación se escriban en el disco montado en /mnt en vez de permanecer en memoria. Esto es necesario debido a que la primera fase de la orden guix system init (vea más adelante) implica descargas o construcciones en /gnu/store, el cual, inicialmente, está un sistema de archivos en memoria.

Next, you have to edit a file and provide the declaration of the operating system to be installed. To that end, the installation system comes with three text editors. We recommend GNU nano (see GNU nano Manual), which supports syntax highlighting and parentheses matching; other editors include mg (an Emacs clone), and nvi (a clone of the original BSD vi editor). We strongly recommend storing that file on the target root file system, say, as /mnt/etc/config.scm. Failing to do that, you will have lost your configuration file once you have rebooted into the newly-installed system.

See Uso de la configuración del sistema, para hacerse una idea del archivo de configuración. Las configuraciones de ejemplo mencionadas en esa sección están disponibles bajo /etc/configuration en la imagen de instalación. Por tanto, para empezar con una configuración del sistema que proporcione un servidor gráfico (un sistema de “escritorio”), puede ejecutar algo parecido a estas órdenes:

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

Debe prestar atención a lo que su archivo de configuración contiene, y en particular:

Una vez haya terminado de preparar el archivo de configuración, el nuevo sistema debe ser inicializado (recuerde que el sistema de archivos raíz deseado está montado bajo /mnt):

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

Esto copia todos los archivos necesarios e instala GRUB en /dev/sdX, a menos que proporcione la opción --no-bootloader. Para más información, see Invocación de guix system. Esta orden puede desencadenar descargas o construcciones de paquetes no encontrados, lo cual puede tomar algún tiempo.

Una vez que la orden se complete—¡y, deseablemente, de forma satisfactoria!—puede ejecutar reboot y arrancar con el nuevo sistema. La contraseña de root en el nuevo sistema está vacía inicialmente; otras contraseñas de usuarias tienen que ser inicializadas ejecutando la orden passwd como root, a menos que en su configuración se especifique de otra manera (see contraseñas de cuentas de usuaria). ¡See Tras la instalación del sistema para proceder a continuación!


Next: , Previous: , Up: Instalación del sistema   [Contents][Index]

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 Invocación de 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!


Next: , Previous: , Up: Instalación del sistema   [Contents][Index]

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-df72ba9.sistema.iso
    

    -enable-kvm es opcional, pero mejora el rendimiento significativamente, see Ejecutar 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 Ejecutar Guix en una máquina virtual, para información sobre cómo hacerlo.


Previous: , Up: Instalación del sistema   [Contents][Index]

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 Invocación de 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.


Next: , Previous: , Up: Top   [Contents][Index]

4 Empezando

Es probable que haya llegado a esta sección o bien porque haya instalado Guix sobre otra distribución (see Instalación), o bien porque haya instalado el sistema Guix completo (see Instalación del sistema). Es hora de dar sus primeros pasos con Guix; esta sección intenta ser de ayuda con estos primeros pasos y proporcionar una primera impresión sobre Guix.

Guix está orientado a instalar software, por lo que probablemente la primera cosa que deseará hacer es mirar el software disponible. Digamos, por ejemplo, que busca un editor de texto. Para ello puede ejecutar:

guix search texto editor

Esta orden le muestra cierto número de paquetes asociados a dicha búsqueda, mostrando con cada uno de ellos su nombre, versión, una descripción e información adicional. Una vez que ha encontrado el que quiere usar, digamos Emacs (je je je), puede seguir adelante e instalarlo (ejecute esta orden con su cuenta de usuaria habitual, ¡no necesita privilegios de administración o usar la cuenta “root”!):

guix install emacs

You’ve installed your first package, congrats! The package is now visible in your default profile, $HOME/.guix-profile—a profile is a directory containing installed packages. In the process, you’ve probably noticed that Guix downloaded pre-built binaries; or, if you explicitly chose to not use pre-built binaries, then probably Guix is still building software (see Sustituciones, for more info).

Si no está usando el sistema Guix, la orden guix install debe haber mostrado este consejo:

consejo: Considere proporcionar valor a las variables de entorno necesarias ejecutando:
     GUIX_PROFILE="$HOME/.guix-profile"
     . "$GUIX_PROFILE/etc/profile"

Alternativamente, véase `guix package --search-paths -p "$HOME/.guix-profile"'.

Indeed, you must now tell your shell where emacs and other programs installed with Guix are to be found. Pasting the two lines above will do just that: it will add $HOME/.guix-profile/bin—which is where the installed package is—to the PATH environment variable. You can paste these two lines in your shell so they take effect right away, but more importantly you should add them to ~/.bash_profile (or equivalent file if you do not use Bash) so that environment variables are set next time you spawn a shell. You only need to do this once and other search paths environment variables will be taken care of similarly—e.g., if you eventually install python and Python libraries, GUIX_PYTHONPATH will be defined.

Puede continuar instalando paquetes cuando quiera. Para enumerar los paquetes instalados, ejecute:

guix package --list-installed

Para borrar un paquete, deberá ejecutar guix remove. Una característica distintiva es la capacidad de revertir cualquier operación que haya realizado—instalación, borrado, actualización—simplemente escribiendo:

guix package --roll-back

Esto es debido al hecho de que cada operación en realidad es una transacción que crea una nueva generación. Estas generaciones y la diferencia entre ellas puede ser visualizada mediante la ejecución de:

guix package --list-generations

¡Ahora ya conoce lo básico sobre gestión de paquetes!

Más allá: See Gestión de paquetes, para más información sobre gestión de paquetes. Puede que le guste la gestión declarativa de paquetes con guix package --manifest, la gestión de distintos perfiles con --profile, el borrado de generaciones antiguas, la recolección de basura y otras interesantes características que le serán útiles una vez que se familiarice con Guix. Si es desarrolladora, see Desarrollo para herramientas adicionales. Y si simplemente tiene curiosidad, see Características, para echar un vistazo a su funcionamiento interno.

Una vez que haya instalado un conjunto de paquetes, deseará actualizarlos periódicamente a la última y mejor versión. Para hacerlo, primero debe obtener la última revisión de Guix y su colección de paquetes:

guix pull

El resultado final es un nuevo ejecutable guix, que se encuentra en ~/.config/guix/current/bin. A menos que use el sistema Guix, asegúrese de seguir el consejo que la orden muestra y, al igual que vimos previamente, pegue estas dos líneas en su terminal y en .bash_profile:

GUIX_PROFILE="$HOME/.config/guix/current"
. "$GUIX_PROFILE/etc/profile"

También le debe indicar a su intérprete que haga referencia a este nuevo guix:

hash guix

En este momento ya está ejecutando una nueva instalación de Guix. Por lo tanto puede continuar y actualizar todos los paquetes que haya instalado previamente:

guix upgrade

Mientras se ejecuta esta orden verá que se descargan binarios (o quizá que algunos paquetes se construyen) y tras cierto tiempo obtendrá los paquetes actualizados. ¡Recuerde que siempre puede revertir esta acción en caso de que uno de los paquetes no sea de su agrado!

Puede mostrar la revisión exacta de Guix que está ejecutando mediante la orden:

guix describe

La información que muestra contiene todo lo necesario para reproducir exactamente el mismo Guix, ya sea en otro momento o en una máquina diferente.

Más allá: See Invocación de guix pull, para más información. See Canales, para saber cómo especificar canales adicionales de los que obtener paquetes, cómo replicar Guix y más información. La orden time-machine también le puede ser de utilidad (see Invocación de guix time-machine).

Si ha instalado el sistema Guix, una de las primeras cosas que probablemente desee hacer es actualizar su sistema. Una vez que haya ejecutado guix pull con la última versión de Guix, puede actualizar su sistema de este modo:

sudo guix system reconfigure /etc/config.scm

Tras su finalización, el sistema ejecuta las últimas versiones de sus paquetes de software. Cuando reinicie el sistema verá un menú en el cargador de arranque que dice “GNU system, old configurations...”: es lo que le permite arrancar una generación anterior de su sistema, en caso de que la generación actual falle o resulte insatisfactoria de algún otro modo. Al igual que con los paquetes, siempre puede revertir el sistema completo a una generación previa:

sudo guix system roll-back

Habrá muchas cosas que probablemente quiera modificar su sistema para que se adapte a sus necesidades: añadir nuevas cuentas de acceso, nuevos servicios del sistema, modificar la configuración de esos servicios, etcétera. La configuración del sistema se describe al completo en el archivo /etc/config.scm. See Uso de la configuración del sistema para aprender cómo cambiarla.

¡Ya sabe lo suficiente para empezar!

Recursos: El resto de este manual proporciona una referencia para Guix al completo. Esta es una lista de recursos adicionales que le pueden resultar útiles:

¡Esperamos que disfrute Guix tanto como la comunidad disfruta en su construcción!


Next: , Previous: , Up: Top   [Contents][Index]

5 Gestión de paquetes

El propósito de GNU Guix es permitir a las usuarias instalar, actualizar y borrar fácilmente paquetes de software, sin tener que conocer acerca de sus procedimientos de construcción o dependencias. Guix también va más allá de este conjunto obvio de características.

Este capítulo describe las principales características de Guix, así como las herramientas de gestión de paquetes que ofrece. Junto a la interfaz de línea de órdenes descrita a continuación (see guix package, también puede usar la interfaz Emacs-Guix (see The Emacs Guix Reference Manual), tras la instalación del paquete emacs-guix (ejecute la orden M-x guix-help para iniciarse en su uso):

guix install emacs-guix

Next: , Up: Gestión de paquetes   [Contents][Index]

5.1 Características

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

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

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

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

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

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

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.


Next: , Previous: , Up: Gestión de paquetes   [Contents][Index]

5.2 Invocación de guix package

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

guix package opciones

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

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

guix package -r lua -i guile guile-cairo

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

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.

Cada paquete puede especificar un nombre simple de paquete, como por ejemplo guile, o un nombre de paquete seguido por una arroba y el número de versión, como por ejemplo guile@1.8.8 o simplemente guile@1.8 (en el último caso la última versión con 1.8 como prefijo es seleccionada).

Si no se especifica un número de versión, la última versión disponible será seleccionada. Además, paquete puede contener dos puntos, seguido por el nombre de una de las salidas del paquete, como en gcc:doc o binutils@2.22:lib (see Paquetes con múltiples salidas). Los paquetes con el nombre correspondiente (y opcionalmente la versión) se buscan entre los módulos de la distribución GNU (see Módulos de paquetes).

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 mesa11 (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:

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


Next: , Previous: , Up: Gestión de paquetes   [Contents][Index]

5.3 Sustituciones

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

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


Next: , Up: Sustituciones   [Contents][Index]

5.3.1 Official Substitute Servers

ci.guix.gnu.org and bordeaux.guix.gnu.org are both front-ends to official build farms that build packages from Guix continuously for some architectures, and make them available as substitutes. These are the default source of substitutes; which can be overridden by passing the --substitute-urls option either to guix-daemon (see guix-daemon --substitute-urls) or to client tools such as guix package (see client --substitute-urls option).

Las URLs de sustituciones pueden ser tanto HTTP como HTTPS. Se recomienda HTTPS porque las comunicaciones están cifradas; de modo contrario, usar HTTP hace visibles todas las comunicaciones para alguien que las intercepte, quien puede usar la información obtenida para determinar, por ejemplo, si su sistema tiene vulnerabilidades de seguridad sin parchear.

Substitutes from the official build farms are enabled by default when using Guix System (see Distribución GNU). However, they are disabled by default when using Guix on a foreign distribution, unless you have explicitly enabled them via one of the recommended installation steps (see Instalación). The following paragraphs describe how to enable or disable substitutes for the official build farm; the same procedure can also be used to enable substitutes for any other substitute server.


Next: , Previous: , Up: Sustituciones   [Contents][Index]

5.3.2 Autorización de servidores de sustituciones

To allow Guix to download substitutes from ci.guix.gnu.org, bordeaux.guix.gnu.org or a mirror, you must add the relevant public key to the access control list (ACL) of archive imports, using the guix archive command (see Invocación de guix archive). Doing so implies that you trust the substitute server to not be compromised and to serve genuine substitutes.

Nota: If you are using Guix System, you can skip this section: Guix System authorizes substitutes from ci.guix.gnu.org and bordeaux.guix.gnu.org by default.

The public keys for each of the project maintained substitute servers are installed along with Guix, in prefix/share/guix/, where prefix is the installation prefix of Guix. If you installed Guix from source, make sure you checked the GPG signature of guix-df72ba9.tar.gz, which contains this public key file. Then, you can run something like this:

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

Una vez esté autorizada, la salida de una orden como guix build debería cambiar de algo como:

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

a algo así:

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

The text changed from “The following derivations would be built” to “112.3 MB would be downloaded”. This indicates that substitutes from the configured substitute servers are usable and will be downloaded, when possible, for future builds.

El mecanismo de sustituciones puede ser desactivado globalmente ejecutando guix-daemon con --no-subsitutes (see Invocación de guix-daemon). También puede ser desactivado temporalmente pasando la opción --no-substitutes a guix package, guix build y otras herramientas de línea de órdenes.


Next: , Previous: , Up: Sustituciones   [Contents][Index]

5.3.3 Obtención de sustiticiones desde otros servidores

Guix puede buscar y obtener sustituciones a partir de varios servidores. Esto es útil cuando se usan paquetes de canales adicionales para los que el servidor oficial no proporciona sustituciones pero otros servidores sí. Otra situación donde puede esta característica puede ser útil es en el caso de que prefiera realizar las descargas desde el servidor de sustituciones de su organización, accediendo al servidor oficial únicamente como mecanismo de salvaguarda o no usándolo en absoluto.

Puede proporcionarle a Guix una lista de URL de servidores de los que obtener sustituciones y las comprobará en el orden especificado. También es necesario que autorice explícitamente las claves públicas de los servidores de sustituciones para que Guix acepte las sustituciones firmadas por dichos claves.

En el sistema Guix esto se consigue modificando la configuración del servicio guix. Puesto que el servicio guix es parte de las listas de servicios predeterminadas, %base-services y %desktop-services, puede usar modify-services para cambiar su configuración y añadir las URL y claves para sustituciones que desee (see modify-services).

As an example, suppose you want to fetch substitutes from guix.example.org and to authorize the signing key of that server, in addition to the default ci.guix.gnu.org and bordeaux.guix.gnu.org. The resulting operating system configuration will look something like:

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

Esto asume que el archivo clave.pub contiene la clave de firma de guix.example.org. Cuando haya realizado este cambio en el archivo de configuración de su sistema operativo (digamos /etc/config.scm), puede reconfigurar y reiniciar el servicio guix-daemon o reiniciar la máquina para que los cambios se hagan efectivos:

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

Si por el contrario ejecuta Guix sobre una distribución distinta, deberá llevar a cabo los siguientes pasos para obtener sustituciones de servidores adicionales:

  1. Edite el archivo de configuración para el servicio de guix-daemon; cuando use systemd normalmente se trata de /etc/systemd/system/guix-daemon.service. Añada la opción --substitute-urls en la línea de ordenes de guix-daemon y la lista de URL que desee (see guix-daemon --substitute-urls):
    … --substitute-urls='https://guix.example.org https://ci.guix.gnu.org https://bordeaux.guix.gnu.org'
    
  2. Reinicie el daemon. Con systemd estos son los pasos:
    systemctl daemon-reload
    systemctl restart guix-daemon.service
    
  3. Autorice la clave del nuevo servidor (see Invocación de guix archive):
    guix archive --authorize < clave.pub
    

    De nuevo se asume que clave.pub contiene la clave pública usada por guix.example.org para firmar las sustituciones.

Now you’re all set! Substitutes will be preferably taken from https://guix.example.org, using ci.guix.gnu.org then bordeaux.guix.gnu.org as fallback options. Of course you can list as many substitute servers as you like, with the caveat that substitute lookup can be slowed down if too many servers need to be contacted.

Tenga en cuenta que existen situaciones en las que se puede desear añadir la URL de un servidor de sustitucines sin autorizar su clave. See Verificación de sustituciones para entender este caso específico.


Next: , Previous: , Up: Sustituciones   [Contents][Index]

5.3.4 Verificación de sustituciones

Guix detecta y emite errores cuando se intenta usar una sustitución que ha sido adulterado. Del mismo modo, ignora las sustituciones que no están firmadas, o que no están firmadas por una de las firmas enumeradas en la ACL.

No obstante hay una excepción: si un servidor no autorizado proporciona sustituciones que son idénticas bit-a-bit a aquellas proporcionadas por un servidor autorizado, entonces el servidor no autorizado puede ser usado para descargas. Por ejemplo, asumiendo que hemos seleccionado dos servidores de sustituciones con esta opción:

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

Si la ACL contiene únicamente la clave para ‘b.example.org’, y si ‘a.example.org’ resulta que proporciona exactamente las mismas sustituciones, Guix descargará sustituciones de ‘a.example.org’ porque viene primero en la lista y puede ser considerado un espejo de ‘b.example.org’. En la práctica, máquinas de construcción independientes producen habitualmente los mismos binarios, gracias a las construcciones reproducibles bit-a-bit (véase a continuación).

Cuando se usa HTTPS, el certificado X.509 del servidor no se valida (en otras palabras, el servidor no está verificado), lo contrario del comportamiento habitual de los navegadores Web. Esto es debido a que Guix verifica la información misma de las sustituciones, como se ha explicado anteriormente, lo cual nos concierne (mientras que los certificados X.509 tratan de verificar las conexiones entre nombres de dominio y claves públicas).


Next: , Previous: , Up: Sustituciones   [Contents][Index]

5.3.5 Configuración de la pasarela.

Substitutes are downloaded over HTTP or HTTPS. The http_proxy and https_proxy environment variables can be set in the environment of guix-daemon and are honored for downloads of substitutes. Note that the value of those environment variables in the environment where guix build, guix package, and other client commands are run has absolutely no effect.


Next: , Previous: , Up: Sustituciones   [Contents][Index]

5.3.6 Fallos en las sustituciones

Incluso cuando una sustitución de una derivación está disponible, a veces el intento de sustitución puede fallar. Esto puede suceder por varias razones: el servidor de sustituciones puede estar desconectado, la sustitución puede haber sido borrada, la conexión puede interrumpirse, etc.

Cuando las sustituciones están activadas y una sustitución para una derivación está disponible, pero el intento de sustitución falla, Guix intentará construir la derivación localmente dependiendo si se proporcionó la opción --fallback (see opción común de construcción --fallback). Específicamente, si no se pasó --fallback, no se realizarán construcciones locales, y la derivación se considera se considera fallida. No obstante, si se pasó --fallback, Guix intentará construir la derivación localmente, y el éxito o fracaso de la derivación depende del éxito o fracaso de la construcción local. Fíjese que cuando las sustituciones están desactivadas o no hay sustituciones disponibles para la derivación en cuestión, la construcción local se realizará siempre, independientemente de si se pasó la opción --fallback.

Para hacerse una idea de cuantas sustituciones hay disponibles en este momento, puede intentar ejecutar la orden guix weather (see Invocación de guix weather). Esta orden proporciona estadísticas de las sustituciones proporcionadas por un servidor.


Previous: , Up: Sustituciones   [Contents][Index]

5.3.7 Sobre la confianza en binarios

Today, each individual’s control over their own computing is at the mercy of institutions, corporations, and groups with enough power and determination to subvert the computing infrastructure and exploit its weaknesses. While using substitutes can be convenient, we encourage users to also build on their own, or even run their own build farm, such that the project run substitute servers are less of an interesting target. One way to help is by publishing the software you build using guix publish so that others have one more choice of server to download substitutes from (see Invocación de guix publish).

Guix tiene los cimientos para maximizar la reproducibilidad de las construcciones (see Características). En la mayor parte de los casos, construcciones independientes de un paquete o derivación dada deben emitir resultados idénticos bit a bit. Por tanto, a través de un conjunto diverso de construcciones independientes de paquetes, podemos reforzar la integridad de nuestros sistemas. La orden guix challenge intenta ayudar a las usuarias en comprobar servidores de sustituciones, y asiste a las desarrolladoras encontrando construcciones no deterministas de paquetes (see Invocación de guix challenge). Similarmente, la opción --check de guix build permite a las usuarias si las sustituciones previamente instaladas son genuinas mediante su reconstrucción local (see guix build --check).

En el futuro, queremos que Guix permita la publicación y obtención de binarios hacia/desde otras usuarias, entre pares (P2P). En caso de interesarle hablar sobre este proyecto, unase a nosotras en guix-devel@gnu.org.


Next: , Previous: , Up: Gestión de paquetes   [Contents][Index]

5.4 Paquetes con múltiples salidas

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

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

guix install glib

La orden que instala su documentación es:

guix install glib:doc

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


Next: , Previous: , Up: Gestión de paquetes   [Contents][Index]

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

Antes de comenzar el proceso de recolección de basura, borra todas las generaciones anteriores a duración, para todos los perfiles de la usuaria; cuando se ejecuta como root esto aplica a los perfiles de todas las usuarias.

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.


Next: , Previous: , Up: Gestión de paquetes   [Contents][Index]

5.6 Invocación de guix pull

Los paquetes se instalan o actualizan con la última versión disponible en la distribución disponible actualmente en su máquina local. Para actualizar dicha distribución, junto a las herramientas de Guix, debe ejecutar guix pull: esta orden descarga el último código fuente de Guix y descripciones de paquetes, y lo despliega. El código fuente se descarga de un repositorio Git, por defecto el repositorio oficial de GNU Guix, lo que no obstante puede ser personalizado. guix pull se asegura que el código que descarga es auténtico verificando que revisiones están firmadas por desarrolladoras de Guix.

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

Descarga el código para el canal guix de la url especificada, en la revisión proporcionada (un ID de revisión Git representada como una cadena hexadecimal), o rama.

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


Next: , Previous: , Up: Gestión de paquetes   [Contents][Index]

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

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

Usa el canal guix de la url especificada, en la revisión proporcionada (un ID de revisión Git representada como una cadena hexadecimal), o rama.

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


Next: , Previous: , Up: Gestión de paquetes   [Contents][Index]

5.8 Inferiores

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


Next: , Previous: , Up: Gestión de paquetes   [Contents][Index]

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


Previous: , Up: Gestión de paquetes   [Contents][Index]

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

Next: , Previous: , Up: Top   [Contents][Index]

6 Canales

Guix y su colección de paquetes se actualizan ejecutando guix pull (see Invocación de guix pull). Por defecto guix pull descarga y despliega el mismo Guix del repositorio oficial de GNU Guix. Esto se puede personalizar definiendo canales en el archivo ~/.config/guix/channels.scm. Un canal especifica una URL y una rama de un repositorio Git que será desplegada, y guix pull puede ser instruido para tomar los datos de uno o más canales. En otras palabras, los canales se pueden usar para personalizar y para extender Guix, como vemos a continuación. Guix tiene en cuenta consideraciones de seguridad e implementa actualizaciones verificadas.


Next: , Up: Canales   [Contents][Index]

6.1 Especificación de canales adicionales

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

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

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

$ guix pull --list-generations
…
Generación 19	27 Ago 2018 16:20:48
  guix d894ab8
    URL del repositorio: https://git.savannah.gnu.org/git/guix.git
    rama: master
    revisión: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
  paquetes-personalizados dd3df5e
    repository URL: https://example.org/paquetes-personalizados.git
    rama: master
    revisión: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb
  11 nuevos paquetes: mi-gimp, mi-emacs-con-cosas-bonitas, …
  4 paquetes actualizados: emacs-racket-mode@0.0.2-2.1b78827, …

La salida de guix pull previa muestra que la generación 19 incluye tanto Guix como paquetes del canal paquetes-personalizados. Entre los paquetes nuevos y actualizados que son enumerados, algunos como mi-gimp y mi-emacs-con-cosas-bonitas pueden venir de paquetes-personalizados, mientras que otros vienen del canal predeterminado de Guix.


Next: , Previous: , Up: Canales   [Contents][Index]

6.2 Uso de un canal de Guix personalizado

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

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

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


Next: , Previous: , Up: Canales   [Contents][Index]

6.3 Replicación de Guix

La salida de guix pull --list-generations previa muestra precisamente qué revisiones se usaron para construir esta instancia de Guix. Por tanto podemos replicarla, digamos, en otra máquina, proporcionando una especificaciones de canales en ~/.config/guix/channels.scm que está “clavada” en estas revisiones:

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

The guix describe --format=channels command can even generate this list of channels directly (see Invocación de guix describe). The resulting file can be used with the -C option of guix pull (see Invocación de guix pull) or guix time-machine (see Invocación de guix time-machine).

En este punto las dos máquinas ejecutan exactamente el mismo Guix, con acceso a exactamente los mismos paquetes. La salida de guix build gimp en una máquina debe ser exactamente la misma, bit a bit, que la salida de la misma orden en la otra máquina. Esto también significa que ambas máquinas tienen acceso a todo el código fuente de Guix y, transitivamente, a todo el código fuente de cada paquete que define.

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.


Next: , Previous: , Up: Canales   [Contents][Index]

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


Next: , Previous: , Up: Canales   [Contents][Index]

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


Next: , Previous: , Up: Canales   [Contents][Index]

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

¡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 Módulos 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.


Next: , Previous: , Up: Canales   [Contents][Index]

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

Next: , Previous: , Up: Canales   [Contents][Index]

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


Next: , Previous: , Up: Canales   [Contents][Index]

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


Next: , Previous: , Up: Canales   [Contents][Index]

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


Previous: , Up: Canales   [Contents][Index]

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


Next: , Previous: , Up: Top   [Contents][Index]

7 Desarrollo

Si es una desarrolladora de software, Guix le proporciona herramientas que debería encontrar útiles—independientemente del lenguaje en el que desarrolle actualmente. Esto es sobre lo que trata este capítulo.

The guix shell command provides a convenient way to set up one-off software environments, be it for development purposes or to run a command without installing it in your profile. The guix pack command allows you to create application bundles that can be easily distributed to users who do not run Guix.


Next: , Up: Desarrollo   [Contents][Index]

7.1 Invoking guix shell

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

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

La sintaxis general es:

guix shell [options] [package…]

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

guix shell python python-numpy -- python3

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 environment14; 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;15 --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
--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).


Next: , Previous: , Up: Desarrollo   [Contents][Index]

7.2 Invocación de guix environment

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

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

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

La sintaxis general es:

guix environment opciones paquete

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

guix environment guile

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

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

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


Next: , Previous: , Up: Desarrollo   [Contents][Index]

7.3 Invocación de guix pack

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Next: , Previous: , Up: Desarrollo   [Contents][Index]

7.4 La cadena de herramientas de GCC

Si necesita una cadena de herramientas de desarrollo completa para compilar y enlazar código fuente C o C++, use el paquete gcc-toolchain. Este paquete proporciona una cadena de herramientas GCC para desarrollo C/C++, incluyendo el propio GCC, la biblioteca de C GNU (cabeceras y binarios, más símbolos de depuración de la salida debug), Binutils y un recubrimiento del enlazador.

El propósito del recubrimiento es inspeccionar las opciones -L y -l proporcionadas al enlazador, y los correspondientes parámetros -rpath, y llamar al enlazador real con este nuevo conjunto de parámetros. Puede instruir al recubrimiento para rechazar el enlace contra bibliotecas que no se encuentren en el almacén proporcionando el valor no a la variable de entorno GUIX_LD_WRAPPER_ALLOW_IMPURITIES.

El paquete gfortran-toolchain proporciona una cadena de herramientas de desarrollo completa de GCC para desarrollo en Fortran. Para otros lenguajes por favor use ‘guix search gcc toolchain’ (see Invoking guix package).


Previous: , Up: Desarrollo   [Contents][Index]

7.5 Invocación de guix git authenticate

La orden guix git authenticate verifica una revisión de Git siguiendo las mismas reglas que con los canales (see verificación de canales). Es decir, empezando en una revisión dada, se asegura que todas las revisiones posteriores están firmadas por una clave OpenPGP cuya huella aparece en el archivo .guix-authorizations de su revisión o revisiones antecesoras.

Encontrará útil esta orden si mantiene un canal. Pero de hecho, este sistema de verificación es útil en un contexto más amplio, por lo que quizá quiera usarlo para repositorios de Git que no estén relacionados con Guix.

La sintaxis general es:

guix git authenticate revisión firma [opciones…]

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


Next: , Previous: , Up: Top   [Contents][Index]

8 Interfaz programática

GNU Guix proporciona viarias interfaces programáticas Scheme (APIs) para definir, construir y consultar paquetes. La primera interfaz permite a las usuarias escribir definiciones de paquetes a alto nivel. Estas definiciones referencian conceptos familiares de empaquetamiento, como el nombre y la versión de un paquete, su sistema de construcción y sus dependencias. Estas definiciones se pueden convertir en acciones concretas de construcción.

Las acciones de construcción son realizadas por el daemon Guix, en delegación de las usuarias. En una configuración estándar, el daemon tiene acceso de escritura al almacén—el directorio /gnu/store—mientras que las usuarias no. En la configuración recomendada el daemon también realiza las construcciones en chroots, bajo usuarias específicas de construcción, para minimizar la interferencia con el resto del sistema.

Las APIs de nivel más bajo están disponibles para interactuar con el daemon y el almacén. Para instruir al daemon para realizar una acción de construcción, las usuarias realmente proporcionan una derivación. Una derivación es una representación de bajo nivel de las acciones de construcción a tomar, y el entorno en el que deberían suceder—las derivaciones son a las definiciones de paquetes lo que es el ensamblador a los programas en C. El término “derivación” viene del hecho de que los resultados de la construcción derivan de ellas.

Este capítulo describe todas estas APIs en orden, empezando por las definiciones de alto nivel de paquetes.


Next: , Up: Interfaz programática   [Contents][Index]

8.1 Módulos de paquetes

Desde un punto de vista programático, las definiciones de paquetes de la distribución GNU se proporcionan por módulos Guile en el espacio de nombres (gnu packages …)19 (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)20. 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.


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.2 Definición de paquetes

La interfaz de alto nivel de las definiciones de paquetes está implementada en los módulos (guix packages) y (guix build-system). Como un ejemplo, la definición de paquete, o receta, para el paquete GNU Hello es como sigue:

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs (list gawk))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

Sin ser una experta en Scheme—pero conociendo un poco de inglés—, la lectora puede haber supuesto el significado de varios campos aquí. Esta expresión asocia la variable hello al objeto <package>, que esencialmente es un registro (see Scheme records in GNU Guile Reference Manual). Este objeto de paquete puede ser inspeccionado usando los procedimientos encontrados en el módulo (guix packages); por ejemplo, (package-name hello) devuelve—¡sorpresa!—"hello".

Con suerte, puede que sea capaz de importar parte o toda la definición del paquete de su interés de otro repositorio, usando la orden guix import (see Invocación de guix import).

En el ejemplo previo, hello se define en un módulo para ella, (gnu packages hello). Técnicamente, esto no es estrictamente necesario, pero es conveniente hacerlo: todos los paquetes definidos en módulos bajo (gnu packages …) se reconocen automáticamente en las herramientas de línea de órdenes (see Módulos de paquetes).

Hay unos pocos puntos que merece la pena destacar de la definición de paquete previa:

See Referencia de package, para una descripción completa de los campos posibles.

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.


Next: , Up: Definición de paquetes   [Contents][Index]

8.2.1 Referencia de package

Esta sección resume todas las opciones disponibles en declaraciones package (see Definición de paquetes).

Tipo de datos: package

Este es el tipo de datos que representa la receta de un paquete.

name

El nombre del paquete, como una cadena.

version

The version of the package, as a string. See Versiones numéricas, for guidelines.

source

Un objeto que determina cómo se debería obtener el código fuente del paquete. La mayor parte del tiempo, es un objeto origin, que denota un archivo obtenido de Internet (see Referencia de origin). También puede ser cualquier otro objeto “tipo-archivo” como local-file, que denota un archivo del sistema local de archivos (see local-file).

build-system

El sistema de construcción que debe ser usado para construir el paquete (see Sistemas de construcción).

arguments (predeterminados: '())

Los parámetros que deben ser pasados al sistema de construcción. Es una lista que normalmente contiene una secuencia de pares de palabra clave y valor.

inputs (predeterminadas: '())
native-inputs (predeterminadas: '())
propagated-inputs (predeterminadas: '())

These fields list dependencies of the package. Each element of these lists is either a package, origin, or other “file-like object” (see Expresiones-G); to specify the output of that file-like object that should be used, pass a two-element list where the second element is the output (see Paquetes con múltiples salidas, for more on package outputs). For example, the list below specifies three inputs:

(list libffi libunistring
      `(,glib "bin"))      ;the "bin" output of GLib

In the example above, the "out" output of libffi and libunistring is used.

Compatibility Note: Until version 1.3.0, input lists were a list of tuples, where each tuple has a label for the input (a string) as its first element, a package, origin, or derivation as its second element, and optionally the name of the output thereof that should be used, which defaults to "out". For example, the list below is equivalent to the one above, but using the old input style:

;; Old input style (deprecated).
`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;the "bin" output of GLib

This style is now deprecated; it is still supported but support will be removed in a future version. It should not be used for new package definitions. See Invoking guix style, on how to migrate to the new style.

La distinción entre native-inputs y inputs es necesaria cuando se considera la compilación cruzada. Cuando se compila desde una arquitectura distinta, las dependencias enumeradas en inputs son construidas para la arquitectura objetivo; de modo contrario, las dependencias enumeradas en native-inputs se construyen para la arquitectura de la máquina de construcción.

native-inputs se usa típicamente para enumerar herramientas necesarias en tiempo de construcción, pero no en tiempo de ejecución, como Autoconf, Automake, pkg-config, Gettext o Bison. guix lint puede informar de probables errores en este área (see Invocación de guix lint).

Por último, propagated-inputs es similar a inputs, pero los paquetes especificados se instalarán automáticamente a los perfiles (see el rol de los perfiles en Guix) junto al paquete al que pertenecen (see guix package, para información sobre cómo guix package gestiona las entradas propagadas).

Por ejemplo esto es necesario cuando se empaqueta una biblioteca C/C++ que necesita cabeceras de otra biblioteca para compilar, o cuando un archivo pkg-config se refiere a otro a través de su campo Requires.

Otro ejemplo donde propagated-inputs es útil es en lenguajes que carecen de la facilidad de almacenar la ruta de búsqueda de tiempo de ejecución de la misma manera que el campo RUNPATH de los archivos ELF; esto incluye Guile, Python, Perl y más. Cuando se empaquetan bibliotecas escritas en estos lenguajes, enumerar en propagated-inputs en vez de en inputs las dependencias de tiempo de ejecución permite asegurarse de encontrar el código de las bibliotecas de las que dependan en tiempo de ejecución.

outputs (predeterminada: '("out"))

La lista de nombres de salidas del paquete. See Paquetes con múltiples salidas, para usos típicos de salidas adicionales.

native-search-paths (predeterminadas: '())
search-paths (predeterminadas: '())

A list of search-path-specification objects describing search-path environment variables honored by the package. See Search Paths, for more on search path specifications.

As for inputs, the distinction between native-search-paths and search-paths only matters when cross-compiling. In a cross-compilation context, native-search-paths applies exclusively to native inputs whereas search-paths applies only to host inputs.

Packages such as cross-compilers care about target inputs—for instance, our (modified) GCC cross-compiler has CROSS_C_INCLUDE_PATH in search-paths, which allows it to pick .h files for the target system and not those of native inputs. For the majority of packages though, only native-search-paths makes sense.

replacement (predeterminado: 1.0)

Esto debe ser o bien #f o bien un objeto package que será usado como reemplazo para ete paquete. See injertos, para más detalles.

synopsis

Una descripción en una línea del paquete.

description

A more elaborate description of the package, as a string in Texinfo syntax.

license

La licencia del paquete; un valor de (guix licenses), o una lista de dichos valores.

home-page

La URL de la página principal del paquete, como una cadena.

supported-systems (predeterminados: %supported-systems)

La lista de sistemas en los que se mantiene el paquete, como cadenas de la forma arquitectura-núcleo, por ejemplo "x86_64-linux".

location (predeterminada: la localización de los fuentes de la forma package)

La localización de las fuentes del paquete. Es útil forzar su valor cuando se hereda de otro paquete, en cuyo caso este campo no se corrige automáticamente.

Sintaxis Scheme: this-package

Cuando se usa en el ámbito léxico de la definición de un paquete, este identificador resuelve al paquete que se está definiendo.

El ejemplo previo muestra cómo añadir un paquete como su propia entrada nativa cuando se compila de forma cruzada:

(package
  (name "guile")
  ;; ...

  ;; When cross-compiled, Guile, for example, depends on
  ;; a native version of itself.  Add it here.
  (native-inputs (if (%current-target-system)
                     (list this-package)
                     '())))

Es un error hacer referencia a this-package fuera de la definición de un paquete.

The following helper procedures are provided to help deal with package inputs.

Scheme Procedure: lookup-package-input package name
Scheme Procedure: lookup-package-native-input package name
Scheme Procedure: lookup-package-propagated-input package name
Scheme Procedure: lookup-package-direct-input package name

Look up name among package’s inputs (or native, propagated, or direct inputs). Return it if found, #f otherwise.

name is the name of a package depended on. Here’s how you might use it:

(use-modules (guix packages) (gnu packages base))

(lookup-package-direct-input coreutils "gmp")
 #<package gmp@6.2.1 …>

In this example we obtain the gmp package that is among the direct inputs of coreutils.

Sometimes you will want to obtain the list of inputs needed to develop a package—all the inputs that are visible when the package is compiled. This is what the package-development-inputs procedure returns.

Scheme Procedure: package-development-inputs package [system] [#:target #f] Return the list of inputs required by

package for development purposes on system. When target is true, return the inputs needed to cross-compile package from system to triplet, where triplet is a triplet such as "aarch64-linux-gnu".

Note that the result includes both explicit inputs and implicit inputs—inputs automatically added by the build system (see Sistemas de construcción). Let us take the hello package to illustrate that:

(use-modules (gnu packages base) (guix packages))

hello
 #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790>

(package-direct-inputs hello)
 ()

(package-development-inputs hello)
 (("source" ) ("tar" #<package tar@1.32 …>) )

In this example, package-direct-inputs returns the empty list, because hello has zero explicit dependencies. Conversely, package-development-inputs includes inputs implicitly added by gnu-build-system that are required to build hello: tar, gzip, GCC, libc, Bash, and more. To visualize it, guix graph hello would show you explicit inputs, whereas guix graph -t bag hello would include implicit inputs (see Invocación de guix graph).

Debido a que los paquetes son objetos Scheme normales que capturan un grafo de dependencias completo y se asocian a procedimientos de construcción, habitualmente es útil escribir procedimientos que toman un paquete y devuelven una versión modificada de acuerdo a ciertos parámetros. A continuación se muestran algunos ejemplos:

Procedimiento Scheme: package-with-c-toolchain paquete cadena

Devuelve una variación de paquete que usa cadena en vez de la cadena de herramientas de construcción de C/C++ de GNU predeterminada. cadena debe ser una lista de entradas (tuplas etiqueta/paquete) que proporcionen una funcionalidad equivalente a la del paquete gcc-toolchain.

El siguiente ejemplo devuelve una variación del paquete hello que se ha construido con GCC 10.x y el resto de la cadena de herramientas de construcción de GNU (Binutils y la biblioteca de C de GNU) en vez de la cadena de construcción predeterminada:

(let ((cadena (specification->package "gcc-toolchain@10")))
  ;; El nombre de la entrada debe ser "toolchain".
  (package-with-c-toolchain hello `(("toolchain" ,cadena))))

La cadena de herramientas de construcción es parte de las entradas impícitas de los paquetes—habitualmente no se enumera como parte de los distintos campos de entrada (“inputs”) sino que el sistema de construcción es quién la incorpora. Por lo tanto este procedimiento funciona cambiando el sistema de construcción del paquete de modo que se incorpora cadena en vez de los valores predeterminados. Sistemas de construcción para obtener más información sobre sistemas de construcción.


Previous: , Up: Definición de paquetes   [Contents][Index]

8.2.2 Referencia de origin

Esta sección documenta los orígenes. Una declaración de origen (origin) especifica datos que se deben “producir”—descargandose, habitualmente—y el hash de su contenido se conoce de antemano. Los origenes se usan habitualmente para reprensentar el código fuente de los paquetes (see Definición de paquetes). Por esta razón la forma sintáctica origin le permite declarar tanto parches para aplicar al código fuente original como fragmentos de código que para su modificación.

Tipo de datos: origin

Este es el tipo de datos que representa un origen de código fuente.

uri

Un objeto que contiene el URI de las fuentes. El tipo de objeto depende del valor de method (véase a continuación). Por ejemplo, cuando se usa el método url-fetch de (guix download), los valores adecuados para uri son: una cadena que contiene una URL, o una lista de cadenas.

method

A monadic procedure that handles the given URI. The procedure must accept at least three arguments: the value of the uri field and the hash algorithm and hash value specified by the hash field. It must return a store item or a derivation in the store monad (see La mónada del almacén); most methods return a fixed-output derivation (see Derivaciones).

Los métodos habitualmente usados incluyen url-fetch, que obtiene datos a partir de una URL, y git-fetch, que obtiene datos de un repositorio Git (véase a continuación).

sha256

Un vector de bytes que contiene el hash SHA-256 de las fuentes. Es equivalente a proporcionar un objeto SHA256 content-hash en el campo hash descrito a continuación.

hash

El objeto content-hash de las fuentes—véase a continuación cómo usar content-hash.

Puede obtener esta información usando guix download (see Invocación de guix download) o guix hash (see Invocación de guix hash).

file-name (predeterminado: #f)

El nombre de archivo bajo el que el código fuente se almacenará. Cuando este es #f, un valor predeterminado sensato se usará en la mayor parte de casos. En caso de que las fuentes se obtengan de una URL, el nombre de archivo de la URL se usará. Para copias de trabajo de sistemas de control de versiones, se recomienda proporcionar el nombre de archivo explícitamente ya que el predeterminado no es muy descriptivo.

patches (predeterminados: '())

Una lista de nombres de archivos, orígenes u objetos tipo-archivo (see objetos “tipo-archivo”) apuntando a parches que deben ser aplicados a las fuentes.

La lista de parches debe ser incondicional. En particular, no puede depender del valor de %current-system o %current-target-system.

snippet (predeterminado: #f)

Una expresión-G (see Expresiones-G) o expresión-S que se ejecutará en el directorio de fuentes. Esta es una forma conveniente de modificar el software, a veces más que un parche.

patch-flags (predeterminadas: '("-p1"))

Una lista de opciones de línea de órdenes que deberían ser pasadas a la orden patch.

patch-inputs (predeterminada: #f)

Paquetes o derivaciones de entrada al proceso de aplicación de los parches. Cuando es #f, se proporciona el conjunto habitual de entradas necesarias para la aplicación de parches, como GNU Patch.

modules (predeterminados: '())

Una lista de módulos Guile que debe ser cargada durante el proceso de aplicación de parches y mientras se ejecuta el código del campo snippet.

patch-guile (predeterminado: #f)

El paquete Guile que debe ser usado durante la aplicación de parches. Cuando es #f se usa un valor predeterminado.

Tipo de datos: content-hash valor [algoritmo]

Construye un objeto del hash del contenido para el algoritmo proporcionado, y con valor como su valor. Cuando se omite algoritmo se asume que es sha256.

valor puede ser una cadena literal, en cuyo caso se decodifica en base32, o un vector de bytes.

Las siguientes opciones equivalentes entre sí:

(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj")
(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"
              sha256)
(content-hash (base32
               "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"))
(content-hash (base64 "kkb+RPaP7uyMZmu4eXPVkM4BN8yhRd8BTHLslb6f/Rc=")
              sha256)

Técnicamente, content-hash se implementa actualmente con un macro. Realiza comprobaciones de seguridad en tiempo de expansión, cuando es posible, como asegurarse de que valor tiene el tamaño adecuado para algoritmo.

Como se ha visto previamente, la forma exacta en la que un origen hace referencia a los datos se determina por su campo method. El módulo (guix download) proporciona el método más común, url-fetch, descrito a continuación.

Procedimiento Scheme: url-fetch url algo-hash hash [nombre] [#:executable? #f]

Devuelve una derivación de salida fija que obtiene datos desde url (una cadena o una lista de cadenas indicando URL alternativas), la cual se espera que tenga el hash hash del tipo algo-hash (un símbolo). De manera predeterminada el nombre de archivo es el identificador final de la URL; de manera opcional se puede usar nombre para especificar un nombre de archivo diferente. Cuando executable? es verdadero se proporciona el permiso de ejecución al archivo descargado.

Cuando una de las URL comienza con mirror://, la parte de la máquina se interpreta como el nombre de un esquema de espejos, obtenido de %mirror-file.

De manera alternativa, cuando URL comienza con file://, devuelve el nombre de archivo del almacén correspondiente.

De igual modo el módulo (guix git-download) define el método de origen git-fetch, que descarga datos de un repositorio de control de versiones Git, y el tipo de datos git-reference, que describe el repositorio y la revisión que se debe obtener.

Procedimiento Scheme: git-fetch url algo-hash hash

Devuelve una derivación de salida fija que obtiene ref, un objeto <git-reference>. El hash recursivo de la salida se espera que tenga el valor hash del tipo algo-hash (un símbolo). Se usa nombre para el nombre de archivo, o un nombre genérico si su valor es #f.

Tipo de datos: git-reference

Este es el tipo de datos que representa una referencia de Git que debe obtener el módulo git-fetch.

url

La URL del repositorio Git que debe clonarse.

commit

This string denotes either the commit to fetch (a hexadecimal string), or the tag to fetch. You can also use a “short” commit ID or a git describe style identifier such as v1.0.1-10-g58d7909c97.

recursive? (predeterminado: #f)

Este valor booleano indica si se obtienen los sub-modulos de Git de manera recursiva.

El siguiente ejemplo representa la etiqueta v2.10 del repositorio de GNU Hello:

(git-reference
  (url "https://git.savannah.gnu.org/git/hello.git")
  (commit "v2.10"))

Es equivalente a la siguiente referencia, la cual nombra de manera explícita la revisión:

(git-reference
  (url "https://git.savannah.gnu.org/git/hello.git")
  (commit "dc7dc56a00e48fe6f231a58f6537139fe2908fb9"))

For Mercurial repositories, the module (guix hg-download) defines the hg-fetch origin method and hg-reference data type for support of the Mercurial version control system.

Scheme Procedure: hg-fetch ref hash-algo hash [name] Return a fixed-output derivation that fetches ref, a

<hg-reference> object. The output is expected to have recursive hash hash of type hash-algo (a symbol). Use name as the file name, or a generic name if #false.


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.3 Definición de variantes de paquetes

Una de las ventajas de Guix es que, dada una definición de paquete, puede derivar fácilmente variantes de dicho paquete—para una versión diferente del origen, con dependencias u opciones de compilación diferentes, diferentes, etcétera. Algunos de estos paquetes personalizados se pueden definir directamente en la línea de ordenes (see Opciones de transformación de paquetes). Esta sección describe cómo definir variantes de paquetes en código. Esto puede ser útil en «manifiestos» (see --manifest) y con su propia colleción de paquetes (see Creación de un canal) entre otros usos.

Como se ha mostrado previamente, los paquetes son objetos de primera clase del lenguage Scheme. El módulo (guix packages) proporciona la forma sintáctica package para definir nuevos objetos de paquetes (see Referencia de package). La forma más fácil de definir una variante de un paquete es usar la palabra clave inherit junto a package. Esto le permite heredar de una definición de paquete y modificar únicamente los campos que desee.

Por ejemplo, a partir de la variable hello, que contiene la definición de la versión actual de GNU Hello, podría definir de esta forma una variante para la versión 2.2 (publicada 2006, ¡con solera!):

(use-modules (gnu packages base))    ;para 'hello'

(define hello-2.2
  (package
    (inherit hello)
    (version "2.2")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0lappv4slgb5spyqbh6yl5r013zv72yqg2pcl30mginf3wdqd8k9"))))))

El ejemplo previo es equivalente a lo que la opción de transformación de paquetes --with-source realiza. Esencialmente hello-2.2 preserva todos los campos de hello, excepto version y source, los cuales se modifican. Tenca en cuenta que la variable original hello todavía está disponible en el módulo (gnu packages base) sin sufrir ningún cambio. Cuando define un paquete personalizado como este realmente está añadiendo una nueva definición de paquete; la orignal sigue disponible.

De igual manera puede definir variantes con un conjunto de dependencias distinto al del paquete original. Por ejemplo, el paquete gdb predeterminado depende de guile pero, puesto que es una dependencia opcional, podría definir una variante que elimina dicha dependencia de este modo:

(use-modules (gnu packages gdb))   ;for 'gdb'

(define gdb-sans-guile
  (package
    (inherit gdb)
    (inputs (modify-inputs (package-inputs gdb)
              (delete "guile")))))

The modify-inputs form above removes the "guile" package from the inputs field of gdb. The modify-inputs macro is a helper that can prove useful anytime you want to remove, add, or replace package inputs.

Scheme Syntax: modify-inputs inputs clauses

Modify the given package inputs, as returned by package-inputs & co., according to the given clauses. Each clause must have one of the following forms:

(delete name…)

Delete from the inputs packages with the given names (strings).

(append package…)

Add packages to the end of the input list.

(prepend package…)

Add packages to the front of the input list.

The example below removes the GMP and ACL inputs of Coreutils and adds libcap to the back of the input list:

(modify-inputs (package-inputs coreutils)
  (delete "gmp" "acl")
  (append libcap))

The example below replaces the guile package from the inputs of guile-redis with guile-2.2:

(modify-inputs (package-inputs guile-redis)
  (replace "guile" guile-2.2))

The last type of clause is prepend, to add inputs to the front of the list.

En ciertos casos encontrará útil escribir funciones («procedimientos» en el vocabulario de Scheme) que devuelven un paquete en base a ciertos parámetros. Por ejemplo, considere la biblioteca luasocket para el lenguaje de programación Lua. Se desea crear paquetes de luasocket para las versiones mayores de Lua. Una forma de hacerlo es definir un procedimiento que recibe un paquete Lua y devuelve un paquete luasocket que depende de él:

(define (make-lua-socket name lua)
  ;; Return a luasocket package built with LUA.
  (package
    (name name)
    (version "3.0")
    ;; several fields omitted
    (inputs (list lua))
    (synopsis "Socket library for Lua")))

(define-public lua5.1-socket
  (make-lua-socket "lua5.1-socket" lua-5.1))

(define-public lua5.2-socket
  (make-lua-socket "lua5.2-socket" lua-5.2))

En este ejemplo se han definido los paquetes lua5.1-socket y lua5.2-socket llamando a crea-lua-socket con distintos parámetros. See Procedures in GNU Guile Reference Manual para más información sobre procedimientos. El hecho de disponer de definiciones públicas de nivel superior de estos dos paquetes permite que se les haga referencia desde la línea de órdenes (see Módulos de paquetes).

Estas son variantes muy simples. Para facilitar esta tarea, el módulo (guix transformations) proporciona una interfaz de alto nivel que se corresponde directamente con las opciones de transformación de paquetes más sofisticadas (see Opciones de transformación de paquetes):

Procedimiento Scheme: options->transformation opciones

Devuelve un procedimiento que, cuando se le proporciona un objeto que construir (paquete, derivación, etc.), aplica las transformaciones especificadas en opciones y devuelve los objetos resultantes. opciones debe ser una lista de pares símbolo/cadena como los siguientes:

((with-branch . "guile-gcrypt=master")
 (without-tests . "libgcrypt"))

Cada símbolo nombra una transformación y la cadena correspondiente es el parámetro de dicha transformación.

Por ejemplo, un manifiesto equivalente a esta orden:

guix build guix \
  --with-branch=guile-gcrypt=master \
  --with-debug-info=zlib

... sería algo parecido a esto:

(use-modules (guix transformations))

(define transforma
  ;; El procedimiento de transformación del paquete.
  (options->transformation
   '((with-branch . "guile-gcrypt=master")
     (with-debug-info . "zlib"))))

(packages->manifest
 (list (transforma (specification->package "guix"))))

El procedimiento options->transformation es conveniente, pero quizá no es tan flexible como pudiese desear. ¿Cómo se ha implementado? Es posible que ya se haya percatado de que la mayoría de las opciones de transformación de paquetes van más allá de los cambios superficiales mostrados en los primeros ejemplos de esta sección: implican reescritura de entradas, lo que significa que el grafo de dependencias de un paquete se reescribe sustituyendo entradas específicas por otras.

La reescritura del grafo de dependencias, con el propósito de reemplazar paquetes del grafo, es implementada por el procedimiento package-input-rewriting en (guix packages).

Procedimiento Scheme: package-input-rewriting reemplazos [nombre-reescrito] [#:deep? #t]

Devuelve un procedimiento que, cuando se le pasa un paquete, reemplaza sus dependencias directas e indirectas, incluyendo sus entradas implícitas cuando deep? es verdadero, de acuerdo a reemplazos. reemplazos es una lista de pares de paquetes; el primer elemento de cada par es el paquete a reemplazar, el segundo es el reemplazo.

Opcionalmente, nombre-reescrito es un procedimiento de un parámetro que toma el nombre del paquete y devuelve su nuevo nombre tras la reescritura.

Considere este ejemplo:

(define libressl-en-vez-de-openssl
  ;; Esto es un procedimiento para reemplazar OPENSSL
  ;; por LIBRESSL, recursivamente.
  (package-input-rewriting `((,openssl . ,libressl))))

(define git-con-libressl
  (libressl-en-vez-de-openssl git))

Aquí primero definimos un procedimiento de reescritura que substituye openssl por libressl. Una vez hecho esto, lo usamos para definir una variante del paquete git que usa libressl en vez de openssl. Esto es exactamente lo que hace la opción de línea de órdenes --with-input (see --with-input).

La siguiente variante de package-input-rewriting puede encontrar paquetes a reemplazar por su nombre en vez de por su identidad.

Procedimiento Scheme: package-input-rewriting/spec reemplazos [#:deep? #t]

Devuelve un procedimiento que, proporcionado un paquete, realiza los reemplazos proporcionados sobre todo el grafo del paquete, incluyendo las entradas implícitas a menos que deep? sea falso. reemplazos es una lista de pares de especificación y procedimiento; cada especificación es una especificación de paquete como "gcc" o "guile@2", y cada procedimiento toma un paquete que corresponda con la especificación y devuelve un reemplazo para dicho paquete.

El ejemplo previo podría ser reescrito de esta forma:

(define libressl-en-vez-de-openssl
  ;; Reemplaza todos los paquetes llamados "openssl" con LibreSSL.
  (package-input-rewriting/spec `(("openssl" . ,(const libressl)))))

La diferencia principal en este caso es que, esta vez, los paquetes se buscan por su especificación y no por su identidad. En otras palabras, cualquier paquete en el grafo que se llame openssl será reemplazado.

Un procedimiento más genérico para reescribir el grafo de dependencias de un paquete es package-mapping: acepta cambios arbitrarios sobre nodos del grafo.

Scheme Procedure: package-mapping proc [cortar?] [#:deep? #f]

Devuelve un procedimiento que, dado un paquete, aplica proc a todos los paquetes de los que depende y devuelve el paquete resultante. El procedimiento para la recursión cuando cortar? devuelve verdadero para un paquete dado. Cuando deep? tiene valor verdadero, proc se aplica también a las entradas implícitas.


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.4 Writing Manifests

guix commands let you specify package lists on the command line. This is convenient, but as the command line becomes longer and less trivial, it quickly becomes more convenient to have that package list in what we call a manifest. A manifest is some sort of a “bill of materials” that defines a package set. You would typically come up with a code snippet that builds the manifest, store it in a file, say manifest.scm, and then pass that file to the -m (or --manifest) option that many guix commands support. For example, here’s what a manifest for a simple package set might look like:

;; Manifest for three packages.
(specifications->manifest '("gcc-toolchain" "make" "git"))

Once you have that manifest, you can pass it, for example, to guix package to install just those three packages to your profile (see -m option of guix package):

guix package -m manifest.scm

... or you can pass it to guix shell (see -m option of guix shell) to spawn an ephemeral environment:

guix shell -m manifest.scm

... or you can pass it to guix pack in pretty much the same way (see -m option of guix pack). You can store the manifest under version control, share it with others so they can easily get set up, etc.

But how do you write your first manifest? To get started, maybe you’ll want to write a manifest that mirrors what you already have in a profile. Rather than start from a blank page, guix package can generate a manifest for you (see guix package --export-manifest):

# Write to 'manifest.scm' a manifest corresponding to the
# default profile, ~/.guix-profile.
guix package --export-manifest > manifest.scm

Or maybe you’ll want to “translate” command-line arguments into a manifest. In that case, guix shell can help (see guix shell --export-manifest):

# Write a manifest for the packages specified on the command line.
guix shell --export-manifest gcc-toolchain make git > manifest.scm

In both cases, the --export-manifest option tries hard to generate a faithful manifest; in particular, it takes package transformation options into account (see Opciones de transformación de paquetes).

Nota: Manifests are symbolic: they refer to packages of the channels currently in use (see Canales). In the example above, gcc-toolchain might refer to version 11 today, but it might refer to version 13 two years from now.

If you want to “pin” your software environment to specific package versions and variants, you need an additional piece of information: the list of channel revisions in use, as returned by guix describe. See Replicación de Guix, for more information.

Once you’ve obtained your first manifest, perhaps you’ll want to customize it. Since your manifest is code, you now have access to all the Guix programming interfaces!

Let’s assume you want a manifest to deploy a custom variant of GDB, the GNU Debugger, that does not depend on Guile, together with another package. Building on the example seen in the previous section (see Definición de variantes de paquetes), you can write a manifest along these lines:

(use-modules (guix packages)
             (gnu packages gdb)               ;for 'gdb'
             (gnu packages version-control))  ;for 'git'

;; Define a variant of GDB without a dependency on Guile.
(define gdb-sans-guile
  (package
    (inherit gdb)
    (inputs (modify-inputs (package-inputs gdb)
              (delete "guile")))))

;; Return a manifest containing that one package plus Git.
(packages->manifest (list gdb-sans-guile git))

Note that in this example, the manifest directly refers to the gdb and git variables, which are bound to a package object (see Referencia de package), instead of calling specifications->manifest to look up packages by name as we did before. The use-modules form at the top lets us access the core package interface (see Definición de paquetes) and the modules that define gdb and git (see Módulos de paquetes). Seamlessly, we’re weaving all this together—the possibilities are endless, unleash your creativity!

The data type for manifests as well as supporting procedures are defined in the (guix profiles) module, which is automatically available to code passed to -m. The reference follows.

Data Type: manifest

Data type representing a manifest.

It currently has one field:

entries

This must be a list of manifest-entry records—see below.

Data Type: manifest-entry

Data type representing a manifest entry. A manifest entry contains essential metadata: a name and version string, the object (usually a package) for that entry, the desired output (see Paquetes con múltiples salidas), and a number of optional pieces of information detailed below.

Most of the time, you won’t build a manifest entry directly; instead, you will pass a package to package->manifest-entry, described below. In some unusual cases though, you might want to create manifest entries for things that are not packages, as in this example:

;; Manually build a single manifest entry for a non-package object.
(let ((hello (program-file "hello" #~(display "Hi!"))))
  (manifest-entry
    (name "foo")
    (version "42")
    (item
     (computed-file "hello-directory"
                     #~(let ((bin (string-append #$output "/bin")))
                         (mkdir #$output) (mkdir bin)
                          (symlink #$hello
                                   (string-append bin "/hello")))))))

The available fields are the following:

name
version

Name and version string for this entry.

item

A package or other file-like object (see file-like objects).

output (default: "out")

Output of item to use, in case item has multiple outputs (see Paquetes con múltiples salidas).

dependencies (predeterminadas: '())

List of manifest entries this entry depends on. When building a profile, dependencies are added to the profile.

Typically, the propagated inputs of a package (see propagated-inputs) end up having a corresponding manifest entry in among the dependencies of the package’s own manifest entry.

search-paths (predeterminadas: '())

The list of search path specifications honored by this entry (see Search Paths).

properties (default: '())

List of symbol/value pairs. When building a profile, those properties get serialized.

This can be used to piggyback additional metadata—e.g., the transformations applied to a package (see Opciones de transformación de paquetes).

parent (default: (delay #f))

A promise pointing to the “parent” manifest entry.

This is used as a hint to provide context when reporting an error related to a manifest entry coming from a dependencies field.

Scheme Procedure: concatenate-manifests lst

Concatenate the manifests listed in lst and return the resulting manifest.

Scheme Procedure: package->manifest-entry package [output] [#:properties] Return a manifest entry for the output

of package package, where output defaults to "out", and with the given properties. By default properties is the empty list or, if one or more package transformations were applied to package, it is an association list representing those transformations, suitable as an argument to options->transformation (see options->transformation).

The code snippet below builds a manifest with an entry for the default output and the send-email output of the git package:

(use-modules (gnu packages version-control))

(manifest (list (package->manifest-entry git)
                (package->manifest-entry git "send-email")))
Scheme Procedure: packages->manifest packages

Return a list of manifest entries, one for each item listed in packages. Elements of packages can be either package objects or package/string tuples denoting a specific output of a package.

Using this procedure, the manifest above may be rewritten more concisely:

(use-modules (gnu packages version-control))

(packages->manifest (list git `(,git "send-email")))
Scheme Procedure: package->development-manifest package [system] [#:target] Return a manifest for the development inputs

of package for system, optionally when cross-compiling to target. Development inputs include both explicit and implicit inputs of package.

Like the -D option of guix shell (see guix shell -D), the resulting manifest describes the environment in which one can develop package. For example, suppose you’re willing to set up a development environment for Inkscape, with the addition of Git for version control; you can describe that “bill of materials” with the following manifest:

(use-modules (gnu packages inkscape)          ;for 'inkscape'
             (gnu packages version-control))  ;for 'git'

(concatenate-manifests
 (list (package->development-manifest inkscape)
       (packages->manifest (list git))))

In this example, the development manifest that package->development-manifest returns includes the compiler (GCC), the many supporting libraries (Boost, GLib, GTK, etc.), and a couple of additional development tools—these are the dependencies guix show inkscape lists.

Last, the (gnu packages) module provides higher-level facilities to build manifests. In particular, it lets you look up packages by name—see below.

Scheme Procedure: specifications->manifest specs

Given specs, a list of specifications such as "emacs@25.2" or "guile:debug", return a manifest. Specs have the format that command-line tools such as guix install and guix package understand (see Invocación de guix package).

As an example, it lets you rewrite the Git manifest that we saw earlier like this:

(specifications->manifest '("git" "git:send-email"))

Notice that we do not need to worry about use-modules, importing the right set of modules, and referring to the right variables. Instead, we directly refer to packages in the same way as on the command line, which can often be more convenient.


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.5 Sistemas de construcción

Cada definición de paquete especifica un sistema de construcción y parámetros para dicho sistema de construcción (see Definición de paquetes). Este campo build-system representa el procedimiento de construcción del paquete, así como las dependencias implícitas de dicho procedimiento de construcción.

Los sistemas de construcción son objetos <build-system>. La interfaz para crear y manipularlos se proporciona en el módulo (guix build-system), y otros módulos exportan sistemas de construcción reales.

En su implementación, los sistemas de construcción primero compilan los objetos package a objetos bag. Una bolsa (traducción de bag) es como un paquete, pero con menos ornamentos—en otras palabras, una bolsa es una representación a un nivel más bajo de un paquete, que contiene todas las entradas de dicho paquete, incluyendo algunas implícitamente añadidas por el sistema de construcción. Esta representación intermedia se compila entonces a una derivación (see Derivaciones). EL procedimiento package-with-c-toolchain es un ejemplo de una forma de cambiar las entradas implícitas que el sistema de construcción del paquete incluye (see package-with-c-toolchain).

Los sistemas de construcción aceptan una lista opcional de parámetros. En las definiciones de paquete, estos son pasados vía el campo arguments (see Definición de paquetes). Normalmente son parámetros con palabras clave (see keyword arguments in Guile in GNU Guile Reference Manual). El valor de estos parámetros normalmente se evalúa en la capa de construcción—es decir, por un proceso Guile lanzado por el daemon (see Derivaciones).

El sistema de construcción principal es gnu-build-system, el cual implementa el procedimiento estándar de construcción para GNU y muchos otros paquetes. Se proporciona por el módulo (guix build-system gnu).

Variable Scheme: gnu-build-system

gnu-build-system representa el sistema de construcción GNU y sus variantes (see configuration and makefile conventions in GNU Coding Standards).

In a nutshell, packages using it are configured, built, and installed with the usual ./configure && make && make check && make install command sequence. In practice, a few additional steps are often needed. All these steps are split up in separate phases. See Fases de construcción, for more info on build phases and ways to customize them.

Además, este sistema de construcción asegura que el entorno “estándar” para paquetes GNU está disponible. Esto incluye herramientas como GCC, libc, Coreutils, Bash, Make, Diffutils, grep y sed (vea el módulo (guix build system gnu) para una lista completa). A estas las llamamos las entradas implícitas de un paquete, porque las definiciones de paquete no las mencionan.

This build system supports a number of keyword arguments, which can be passed via the arguments field of a package. Here are some of the main parameters:

#:phases

This argument specifies build-side code that evaluates to an alist of build phases. See Fases de construcción, for more information.

#:configure-flags

This is a list of flags (strings) passed to the configure script. See Definición de paquetes, for an example.

#:make-flags

This list of strings contains flags passed as arguments to make invocations in the build, check, and install phases.

#:out-of-source?

This Boolean, #f by default, indicates whether to run builds in a build directory separate from the source tree.

When it is true, the configure phase creates a separate build directory, changes to that directory, and runs the configure script from there. This is useful for packages that require it, such as glibc.

#:tests?

This Boolean, #t by default, indicates whether the check phase should run the package’s test suite.

#:test-target

This string, "check" by default, gives the name of the makefile target used by the check phase.

#:parallel-build?
#:parallel-tests?

These Boolean values specify whether to build, respectively run the test suite, in parallel, with the -j flag of make. When they are true, make is passed -jn, where n is the number specified as the --cores option of guix-daemon or that of the guix client command (see --cores).

#:validate-runpath?

This Boolean, #t by default, determines whether to “validate” the RUNPATH of ELF binaries (.so shared libraries as well as executables) previously installed by the install phase.

This validation step consists in making sure that all the shared libraries needed by an ELF binary, which are listed as DT_NEEDED entries in its PT_DYNAMIC segment, appear in the DT_RUNPATH entry of that binary. In other words, it ensures that running or using those binaries will not result in a “file not found” error at run time. See -rpath in The GNU Linker, for more information on RUNPATH.

#:substitutable?

This Boolean, #t by default, tells whether the package outputs should be substitutable—i.e., whether users should be able to obtain substitutes for them instead of building locally (see Sustituciones).

#:allowed-references
#:disallowed-references

When true, these arguments must be a list of dependencies that must not appear among the references of the build results. If, upon build completion, some of these references are retained, the build process fails.

This is useful to ensure that a package does not erroneously keep a reference to some of it build-time inputs, in cases where doing so would, for example, unnecessarily increase its size (see Invocación de guix size).

Most other build systems support these keyword arguments.

Hay definidos otros objetos <build-system> para implementar otras convenciones y herramientas usadas por paquetes de software libre. Heredan la mayor parte de gnu-build-system, y se diferencian principalmente en el conjunto de entradas implícitamente añadidas al proceso de construcción, y en la lista de fases ejecutadas. Algunos de estos sistemas de construcción se enumeran a continuación.

Variable Scheme: ant-build-system

(guix build-system ant) exporta esta variable. Implementa el procedimiento de construcción de paquetes Java que pueden construirse con la herramienta de construcción Ant.

Añade tanto ant como el kit de desarrollo Java (JDK), que proporciona el paquete icedtea, al conjunto de entradas. Se pueden especificar paquetes diferentes con los parámetros #:ant y #:jdk, respectivamente.

Cuando el paquete original no proporciona un archivo Ant apropiado, el parámetro #:jar-name puede usarse para generar un archivo de construcción Ant build.xml mínimo con tareas para construir el archivo jar especificado. En este caso, el parámetro #:source-dir se puede usar para especificar el subdirectorio de fuentes, con “src” como valor predeterminado.

The #:main-class parameter can be used with the minimal ant buildfile to specify the main class of the resulting jar. This makes the jar file executable. The #:test-include parameter can be used to specify the list of junit tests to run. It defaults to (list "**/*Test.java"). The #:test-exclude can be used to disable some tests. It defaults to (list "**/Abstract*.java"), because abstract classes cannot be run as tests.

El parámetro #:build-target se puede usar para especificar la tarea Ant que debe ser ejecutada durante la fase build. Por defecto se ejecuta la tarea “jar”.

Variable Scheme: android-ndk-build-system

Esta variable es exportada por (guix build-system android-ndk). Implementa un procedimiento de construcción para paquetes Android NDK (kit de desarrollo nativo) usando un proceso de construcción específico de Guix.

El sistema de construcción asume que los paquetes instalan sus archivos de interfaz pública (cabeceras) en el subdirectorio include de la salida out y sus bibliotecas en el subdirectorio lib de la salida out".

También se asume que la unión de todas las dependencias de un paquete no tiene archivos en conflicto.

En este momento no funciona la compilación cruzada - por lo que las bibliotecas y los archivos de cabecera se asumen que son locales.

Variable Scheme: asdf-build-system/source
Variable Scheme: asdf-build-system/sbcl
Variable Scheme: asdf-build-system/ecl

These variables, exported by (guix build-system asdf), implement build procedures for Common Lisp packages using “ASDF”. ASDF is a system definition facility for Common Lisp programs and libraries.

The asdf-build-system/source system installs the packages in source form, and can be loaded using any common lisp implementation, via ASDF. The others, such as asdf-build-system/sbcl, install binary systems in the format which a particular implementation understands. These build systems can also be used to produce executable programs, or lisp images which contain a set of packages pre-loaded.

El sistema de construcción usa convenciones de nombres. Para paquetes binarios, el paquete debería estar prefijado con la implementación lisp, como sbcl- para asdf-build-system/sbcl.

Adicionalmente, el paquete de fuentes correspondiente debe etiquetarse usando la misma convención que los paquetes python (vea Módulos Python), usando el prefijo cl-.

In order to create executable programs and images, the build-side procedures build-program and build-image can be used. They should be called in a build phase after the create-asdf-configuration phase, so that the system which was just built can be used within the resulting image. build-program requires a list of Common Lisp expressions to be passed as the #:entry-program argument.

By default, all the .asd files present in the sources are read to find system definitions. The #:asd-files parameter can be used to specify the list of .asd files to read. Furthermore, if the package defines a system for its tests in a separate file, it will be loaded before the tests are run if it is specified by the #:test-asd-file parameter. If it is not set, the files <system>-tests.asd, <system>-test.asd, tests.asd, and test.asd will be tried if they exist.

If for some reason the package must be named in a different way than the naming conventions suggest, or if several systems must be compiled, the #:asd-systems parameter can be used to specify the list of system names.

Variable Scheme: cargo-build-system

Esta variable se exporta en (guix build-system cargo). Permite la construcción de paquetes usando Cargo, la herramienta de construcción del lenguaje de programación Rust.

Automáticamente añade rustc y cargo al conjunto de entradas. Se puede especificar el uso de un paquete Rust distinto con el parámetro #:rust.

Regular cargo dependencies should be added to the package definition similarly to other packages; those needed only at build time to native-inputs, others to inputs. If you need to add source-only crates then you should add them to via the #:cargo-inputs parameter as a list of name and spec pairs, where the spec can be a package or a source definition. Note that the spec must evaluate to a path to a gzipped tarball which includes a Cargo.toml file at its root, or it will be ignored. Similarly, cargo dev-dependencies should be added to the package definition via the #:cargo-development-inputs parameter.

In its configure phase, this build system will make any source inputs specified in the #:cargo-inputs and #:cargo-development-inputs parameters available to cargo. It will also remove an included Cargo.lock file to be recreated by cargo during the build phase. The package phase will run cargo package to create a source crate for future use. The install phase installs the binaries defined by the crate. Unless install-source? #f is defined it will also install a source crate repository of itself and unpacked sources, to ease in future hacking on rust packages.

Scheme Variable: chicken-build-system

This variable is exported by (guix build-system chicken). It builds CHICKEN Scheme modules, also called “eggs” or “extensions”. CHICKEN generates C source code, which then gets compiled by a C compiler, in this case GCC.

This build system adds chicken to the package inputs, as well as the packages of gnu-build-system.

The build system can’t (yet) deduce the egg’s name automatically, so just like with go-build-system and its #:import-path, you should define #:egg-name in the package’s arguments field.

For example, if you are packaging the srfi-1 egg:

(arguments '(#:egg-name "srfi-1"))

Egg dependencies must be defined in propagated-inputs, not inputs because CHICKEN doesn’t embed absolute references in compiled eggs. Test dependencies should go to native-inputs, as usual.

Variable Scheme: copy-build-system

Esta variable se exporta en (guix build-system copy). Permite la construcción de paquetes simples que no necesitan mucha compilación y en su mayor parte dependen únicamente de la copia de archivos en distintas rutas.

Añade gran parte de los paquetes de gnu-build-system al conjunto de entradas. Por esta razón, copy-build-system no necesita toda la verborrea que habitualmente requiere trivial-build-system.

Para simplificar más aún el proceso de instalación de archivos, se expone un parámetro #:install-plan para permitir a quien genera el paquete especificar dónde van los distintos archivos. El plan de instalación (#:install-plan) es una lista de (fuente destino [filtro]). Los filtros son opcionales.

Ejemplos:

Variable Scheme: clojure-build-system

Esta variable se exporta en (guix build-system clojure). Implementa un procedimiento de construcción simple para paquetes Clojure usando directamente compile en Clojure. La compilación cruzada no está disponible todavía.

Añade clojure, icedtea y zip al conjunto de entradas. Se pueden especificar paquetes diferentes con los parámetros #:clojure, #:jdk y #:zip, respectivamente.

Una lista de directorios de fuentes, directorios de pruebas y nombres de jar pueden especificarse con los parámetros #:source-dirs, #:test-dirs y #:jar-names, respectivamente. El directorio de compilación y la clase principal pueden especificarse con los parámetros #:compile-dir y #:main-class, respectivamente. Otros parámetros se documentan más adelante.

Este sistema de construcción es una extensión de ant-build-system, pero con las siguientes fases cambiadas:

build

Esta fase llama compile en Clojure para compilar los archivos de fuentes y ejecuta jar para crear archivadores jar tanto de archivos de fuentes y compilados de acuerdo con las listas de inclusión y exclusión especificadas en #:aot-include y #:aot-exclude, respectivamente. La lista de exclusión tiene prioridad sobre la de inclusión. Estas listas consisten en símbolos que representan bibliotecas Clojure o la palabra clave especial #:all que representa todas las bibliotecas encontradas en los directorios de fuentes. El parámetro #:omit-source? determina si las fuentes deben incluirse en los archivadores jar.

check

Esta fase ejecuta las pruebas de acuerdo a las listas de inclusión y exclusión especificadas en #:test-include y #:test-exclude, respectivamente. Sus significados son análogos a los de #:aot-include y #:aot-exclude, excepto que la palabra clave especial #:all designa ahora a todas las bibliotecas Clojure encontradas en los directorios de pruebas. El parámetro #:tests? determina si se deben ejecutar las pruebas.

install

Esta fase instala todos los archivadores jar construidos previamente.

Además de las previas, este sistema de construcción contiene una fase adicional:

install-doc

Esta fase instala todos los archivos de nivel superior con un nombre que corresponda con %doc-regex. Una expresión regular diferente se puede especificar con el parámetro #:doc-regex. Todos los archivos dentro (recursivamente) de los directorios de documentación especificados en #:doc-dirs se instalan también.

Variable Scheme: cmake-build-system

Esta variable se exporta en (guix build-system cmake). Implementa el procedimiento de construcción para paquetes que usen la herramienta de construcción CMake.

Automáticamente añade el paquete cmake al conjunto de entradas. El paquete usado se puede especificar con el parámetro #:cmake.

El parámetro #:configure-flags se toma como una lista de opciones a pasar a cmake. El parámetro #:build-type especifica en términos abstractos las opciones pasadas al compilador; su valor predeterminado es "RelWithDebInfo" (quiere decir “modo de entrega con información de depuración”), lo que aproximadamente significa que el código se compila con -O2 -g, lo cual es el caso predeterminado en paquetes basados en Autoconf.

Variable Scheme: dune-build-system

Esta variable se exporta en (guix build-system dune). Permite la construcción de paquetes mediante el uso de Dune, una herramienta de construcción para el lenguaje de programación OCaml. Se implementa como una extensión de ocaml-build-system que se describe a continuación. Como tal, se pueden proporcionar los parámetros #:ocaml y #:findlib a este sistema de construcción.

Automáticamente añade el paquete dune al conjunto de entradas. El paquete usado se puede especificar con el parámetro #:dune.

No existe una fase configure debido a que los paquetes dune no necesitan ser configurados típicamente. El parámetro #:build-flags se toma como una lista de opciones proporcionadas a la orden dune durante la construcción.

El parámetro #:jbuild? puede proporcionarse para usar la orden jbuild en vez de la más reciente dune durante la construcción de un paquete. Su valor predeterminado es #f.

El parámetro #:package puede proporcionarse para especificar un nombre de paquete, lo que resulta útil cuando un paquete contiene múltiples paquetes y únicamente quiere construir uno de ellos. Es equivalente a proporcionar el parámetro -p a dune.

Variable Scheme: go-build-system

Esta variable se exporta en (guix build-system go). Implementa el procedimiento de construcción para paquetes Go usando los mecanismos de construcción de Go estándares.

Se espera que la usuaria proporcione un valor para el parámetro #:import-path y, en algunos caso, #:unpack-path. La ruta de importación corresponde a la ruta del sistema de archivos esperada por los guiones de construcción del paquete y los paquetes a los que hace referencia, y proporciona una forma de hacer referencia a un paquete Go unívocamente. Está basado típicamente en una combinación de la URI remota del paquete de archivos de fuente y la estructura jerárquica del sistema de archivos. En algunos casos, necesitará desempaquetar el código fuente del paquete en una estructura de directorios diferente a la indicada en la ruta de importación, y #:unpack-path debe usarse en dichos casos.

Los paquetes que proporcionan bibliotecas Go deben instalar su código fuente en la salida de la construcción. El parámetro #:install-source?, cuyo valor por defecto es #t, controla si se instalará o no el código fuente. Puede proporcionarse #f en paquetes que proporcionan únicamente archivos ejecutables.

Packages can be cross-built, and if a specific architecture or operating system is desired then the keywords #:goarch and #:goos can be used to force the package to be built for that architecture and operating system. The combinations known to Go can be found in their documentation.

Variable Scheme: glib-or-gtk-build-system

Esta variable se exporta en (guix build-system glib-or-gtk). Está pensada para usarse con paquetes que usan GLib o GTK+.

Este sistema de construcción añade las dos fases siguientes a las definidas en gnu-build-system:

glib-or-gtk-wrap

La fase glib-or-gtk-wrap se asegura de que los programas en bin/ son capaces de encontrar los “esquemas” GLib y los módulos GTK+. Esto se consigue recubriendo los programas en guiones de lanzamiento que proporcionan valores apropiados para las variables de entorno XDG_DATA_DIRS y GTK_PATH.

Es posible excluir salidas específicas del paquete del proceso de recubrimiento enumerando sus nombres en el parámetro #:glib-org-gtk-wrap-excluded-outputs. Esto es útil cuando se sabe que una salida no contiene binarios GLib o GTK+, y cuando empaquetar gratuitamente añadiría una dependencia de dicha salida en GLib y GTK+.

glib-or-gtk-compile-schemas

La fase glib-or-gtk-compile-schemas se asegura que todos los esquemas GSettings o GLib se compilan. La compilación la realiza el programa glib-compile-schemas. Lo proporciona el paquete glib:bin que se importa automáticamente por el sistema de construcción. El paquete glib que proporciona glib-compile-schemas puede especificarse con el parámetro #:glib.

Ambas fases se ejecutan tras la fase install.

Variable Scheme: guile-build-system

Este sistema de construcción es para paquetes Guile que consisten exclusivamente en código Scheme y son tan simples que no tienen ni siquiera un archivo Makefile, menos un guión configure. Compila código Scheme usando guild compile (see Compilation in GNU Guile Reference Manual) e instala los archivos .scm y .go en el lugar correcto. También instala documentación.

Este sistema de construcción permite la compilación cruzada usando la opción --target de guild compile.

Los paquetes construidos con guile-build-system deben proporcionar un paquete Guile en su campo native-inputs.

Variable Scheme: julia-build-system

This variable is exported by (guix build-system julia). It implements the build procedure used by julia packages, which essentially is similar to running ‘julia -e 'using Pkg; Pkg.add(package)'’ in an environment where JULIA_LOAD_PATH contains the paths to all Julia package inputs. Tests are run by calling /test/runtests.jl.

The Julia package name and uuid is read from the file Project.toml. These values can be overridden by passing the argument #:julia-package-name (which must be correctly capitalized) or #:julia-package-uuid.

Julia packages usually manage their binary dependencies via JLLWrappers.jl, a Julia package that creates a module (named after the wrapped library followed by _jll.jl.

To add the binary path _jll.jl packages, you need to patch the files under src/wrappers/, replacing the call to the macro JLLWrappers.@generate_wrapper_header, adding as a second argument containing the store path the binary.

As an example, in the MbedTLS Julia package, we add a build phase (see Fases de construcción) to insert the absolute file name of the wrapped MbedTLS package:

(add-after 'unpack 'override-binary-path
  (lambda* (#:key inputs #:allow-other-keys)
    (for-each (lambda (wrapper)
                (substitute* wrapper
                  (("generate_wrapper_header.*")
                   (string-append
                    "generate_wrapper_header(\"MbedTLS\", \""
                    (assoc-ref inputs "mbedtls-apache") "\")\n"))))
              ;; There's a Julia file for each platform, override them all.
              (find-files "src/wrappers/" "\\.jl$"))))

Some older packages that aren’t using Project.toml yet, will require this file to be created, too. It is internally done if the arguments #:julia-package-name and #:julia-package-uuid are provided.

Variable Scheme: maven-build-system

Esta variable se exporta en (guix build-system maven). Implementa un procedimiento de construcción para paquetes basados en Maven. Maven es una herramienta para Java de gestión de dependencias y ciclo de vida. Las usuarias de Maven especifican las dependencias y módulos en un archivo pom.xml que Maven lee. Cuando Maven no dispone de una de dichas dependencias o módulos en su repositorio, las descarga y las usa para construir el paquete.

El sistema de compilación de maven se asegura de que maven no intentará descargar ninguna dependencia ejecutándo maven en modo sin conexión. Maven fallará si falta alguna dependencia. Antes de ejecutar Maven, el archivo pom.xml (y los subproyectos) se modifican para especificar la versión de las dependencias y módulos que corresponden a las versiones disponibles en el entorno de construcción de guix. Las dependencias y los módulos se deben instalar en un repositorio de maven ad hoc en lib/m2, y se enlazan un repositorio real antes de que se ejecute maven. Se le indica a Maven que use ese repositorio para la construcción e instale los artefactos generados allí. Los archivos cambiados se copian del directorio lib/m2 a la salida del paquete.

Puede especificar un archivo pom.xml con el parámetro #:pom-file, o dejar al sistema de construcción usar el archivo predeterminado pom.xml en las fuentes.

En caso de que necesite especificar la versión de una dependencia manualmente puede usar el parámetro #:local-packages. Toma como valor una lista asociativa donde la clave es el valor del campo “groupId” del paquete y su valor es una lista asociativa donde la clave es el campo “artifactId” del paquete y su valor la versión que quiere forzar en vez de la que se encuentra en pom.xml.

Algunos paquetes usan dependencias o módulos que no son útiles en tiempo de ejecución ni en tiempo de construcción en Guix. Puede modificar el archivo pom.xml para eliminarlos usando el parámetro #:exclude. Su valor es una lista asociativa donde la clave es el valor del campo “groupId” del módulo o dependencia que quiere eliminar, y su valor es una lista de valores del campo “artifactId” que se eliminarán.

Puede usar valores distintos para los paquetes jdk y maven con el parámetro correspondiente, #:jdk y #:maven.

El parámetro #:maven-plugins es una lista de módulos de maven usados durante la construcción, con el mismo formato que el campo inputs de la declaración del paquete. Su valor predeterminado es (default-maven-plugins) que también se exporta.

Scheme Variable: minetest-mod-build-system

This variable is exported by (guix build-system minetest). It implements a build procedure for Minetest mods, which consists of copying Lua code, images and other resources to the location Minetest searches for mods. The build system also minimises PNG images and verifies that Minetest can load the mod without errors.

Variable Scheme: minify-build-system

Esta variable se exporta en (guix build-system minify). Implementa un procedimiento de minificación para paquetes JavaScript simples.

Añade uglify-js al conjunto de entradas y lo utiliza para comprimir todos los archivos JavaScript en el directorio src. Un paquete de minificación diferente puede especificarse con el parámetro #:uglify-js, pero se espera que el paquete escriba el código minificado en la salida estándar.

Cuando los archivos JavaScript de entrada no se encuentran en el directorio src, el parámetro #:javascript-files puede usarse para especificar una lista de nombres de archivo que proporcionar al minificador.

Variable Scheme: ocaml-build-system

Esta variable se exporta en (guix build-system ocaml). Implementa un procedimiento de construcción para paquetes OCaml, que consiste en seleccionar el conjunto correcto de órdenes a ejecutar para cada paquete. Los paquetes OCaml pueden esperar la ejecución de muchas ordenes diferentes. Este sistema de construcción probará algunas de ellas.

Cuando el paquete tiene un archivo setup.ml presente en el nivel superior, se ejecuta ocaml setup.ml -configure, ocaml setup.ml -build y ocaml setup.ml -install. El sistema de construcción asumirá que este archivo se generó con http://oasis.forge.ocamlcore.org/ OASIS y se encargará de establecer el prefijo y la activación de las pruebas si no se desactivaron. Puede pasar opciones de configuración y construcción con #:configure-flags y #:build-flags, respectivamente. El parámetro #:test-flags puede usarse para cambiar el conjunto de opciones usadas para activar las pruebas. El parámetro #:use-make? puede usarse para ignorar este sistema en las fases de construcción e instalación.

Cuando el paquete tiene un archivo configure, se asume que es un guión de configuración hecho a mano que necesita un formato de parámetros diferente a los del sistema gnu-build-system. Puede añadir más opciones con el parámetro #:configure-flags.

Cuando el paquete tiene un archivo Makefile (o #:use-make? es #t), será usado y se pueden proporcionar más opciones para las fases de construcción y e instalación con el parámetro #:make-flags.

Por último, algunos paquetes no tienen estos archivos y usan unas localizaciones de algún modo estándares para su sistema de construcción. En este caso, el sistema de construcción ejecutará ocaml pkg/pkg.ml o ocaml pkg/build.ml y se hará cargo de proporcionar la ruta del módulo findlib necesario. Se pueden pasar opciones adicionales con el parámetro #:build-flags. De la instalación se hace cargo opam-installer. En este caso, el paquete opam debe añadirse al campo native-inputs de la definición del paquete.

Fíjese que la mayoría de los paquetes OCaml asumen su instalación en el mismo directorio que OCaml, lo que no es el comportamiento deseado en guix. En particular, tratarán de instalar archivos .so en su directorio de módulos, lo que normalmente es aceptable puesto que está bajo el directorio del compilador de OCaml. No obstante, en guix estas bibliotecas no se pueden instalar ahí, por lo que se usa CAML_LD_LIBRARY_PATH. Esta variable apunta a lib/ocaml/site-lib/stubslibs y allí es donde se deben instalar las bibliotecas .so.

Variable Scheme: python-build-system

Esta variable se exporta en (guix build-system python). Implementa el procedimiento más o menos estándar de construcción usado por paquetes Python, que consiste en la ejecución de python setup.py build y python setup.py install --prefix=/gnu/store/….

For packages that install stand-alone Python programs under bin/, it takes care of wrapping these programs so that their GUIX_PYTHONPATH environment variable points to all the Python libraries they depend on.

Se puede especificar el paquete Python usado para llevar a cabo la construcción con el parámetro #:python. Esta es habitualmente una forma de forzar la construcción de un paquete para una versión específica del intérprete Python, lo que puede ser necesario si el paquete es compatible únicamente con una versión del intérprete.

De manera predeterminada guix llama a setup.py bajo el control de setuptools de manera similar a lo realizado por pip. Algunos paquetes no son compatibles con setuptools (y pip), por lo que puede desactivar esta configuración estableciendo el parámetro #:use-setuptools a #f.

If a "python" output is available, the package is installed into it instead of the default "out" output. This is useful for packages that include a Python package as only a part of the software, and thus want to combine the phases of python-build-system with another build system. Python bindings are a common usecase.

Variable Scheme: perl-build-system

Esta variable se exporta en (guix build-system perl). Implementa el procedimiento de construcción estándar para paquetes Perl, lo que o bien consiste en la ejecución de perl Build.PL --prefix=/gnu/store/…, seguido de Build y Build install; o en la ejecución de perl Makefile.PL PREFIX=/gnu/store/…, seguida de make y make install, dependiendo de si Build.PL o Makefile.PL están presentes en la distribución del paquete. El primero tiene preferencia si existen tanto Build.PL como Makefile.PL en la distribución del paquete. Esta preferencia puede ser invertida mediante la especificación del valor #t en el parámetro #:make-maker?.

La invocación inicial de perl Makefile.PL o perl Build.PL pasa a su vez las opciones especificadas por los parámetros #:make-maker-flags o #:module-build-flags, respectivamente.

El paquete Perl usado puede especificarse con #:perl.

Scheme Variable: renpy-build-system

This variable is exported by (guix build-system renpy). It implements the more or less standard build procedure used by Ren’py games, which consists of loading #:game once, thereby creating bytecode for it.

It further creates a wrapper script in bin/ and a desktop entry in share/applications, both of which can be used to launch the game.

Which Ren’py package is used can be specified with #:renpy. Games can also be installed in outputs other than “out” by using #:output.

Variable Scheme: qt-build-system

Esta variable se exporta en (guix build-system qt). Está pensado para usarse con aplicaciones que usen Qt o KDE.

Este sistema de construcción añade las dos fases siguientes a las definidas en cmake-build-system:

check-setup

La fase check-setup prepara el entorno para la ejecución de las comprobaciones usadas habitualmente por los programas de pruebas de Qt. Por ahora únicamente proporciona valor a algunas variables de entorno: QT_QPA_PLATFORM=offscreen, DBUS_FATAL_WARNINGS=0 y CTEST_OUTPUT_ON_FAILURE=1.

Esta fase se añade previamente a la fase check. Es una fase separada para facilitar el ajuste si fuese necesario.

qt-wrap

La fase qt-wrap busca las rutas de módulos de Qt5, las rutas de QML y algunas rutas XDG en las entradas y la salida. En caso de que alguna ruta se encuentra, todos los programas en los directorios bin/, sbin/, libexec/ y lib/libexec/ de la salida se envuelven en guiones que definen las variables de entorno necesarias.

Es posible excluir salidas específicas del paquete del proceso de recubrimiento enumerando sus nombres en el parámetro #:qt-wrap-excluded-outputs. Esto es útil cuando se sabe que una salida no contiene binarios que usen Qt, y cuando empaquetar gratuitamente añadiría una dependencia de dicha salida en Qt.

Ambas fases se añaden tras la fase install.

Variable Scheme: r-build-system

Esta variable se exporta en (guix build-system r). Implementa el procedimiento de construcción usados por paquetes R, lo que esencialmente es poco más que la ejecución de ‘R CMD INSTALL --library=/gnu/store/…’ en un entorno donde R_LIBS_SITE contiene las rutas de todos los paquetes R de entrada. Las pruebas se ejecutan tras la instalación usando la función R tools::testInstalledPackage.

Variable Scheme: rakudo-build-system

This variable is exported by (guix build-system rakudo). It implements the build procedure used by Rakudo for Perl6 packages. It installs the package to /gnu/store/…/NAME-VERSION/share/perl6 and installs the binaries, library files and the resources, as well as wrap the files under the bin/ directory. Tests can be skipped by passing #f to the tests? parameter.

El paquete rakudo en uso puede especificarse con rakudo. El paquete perl6-tap-harness en uso durante las pruebas puede especificarse con #:prove6 o eliminarse proporcionando #f al parámetro with-prove6?. El paquete perl6-zef en uso durante las pruebas e instalación puede especificarse con #:zef o eliminarse proporcionando #f al parámetro with-zef?.

Variable Scheme: texlive-build-system

Esta variable se exporta en (guix build-system texlive). Se usa para construir paquetes TeX en modo de procesamiento de lotes con el motor especificado. El sistema de construcción proporciona valor a la variable TEXINPUTS para encontrar todos los archivos de fuentes TeX en las entradas.

Por defecto ejecuta luatex en todos los archivos que terminan en ins. Un motor y formato diferente puede especificarse con el parámetro #:tex-format. Los diferentes objetivos de construcción pueden especificarse con el parámetro #:build-targets, que espera una lista de nombres de archivo. El sistema de construcción añade únicamente texlive-bin y texlive-latex-base (ambos desde (gnu packages tex) a las entradas. Ambos pueden forzarse con los parámetros #:texlive-bin y #:texlive-latex-base respectivamente.

El parámetro #:tex-directory le dice al sistema de construcción dónde instalar los archivos construidos bajo el árbol texmf.

Variable Scheme: ruby-build-system

Esta variable se exporta en (guix build-system ruby). Implementa el procedimiento de construcción de RubyGems usado por los paquetes Ruby, que implica la ejecución de gem build seguida de gem install.

El campo source de un paquete que usa este sistema de construcción típicamente se refiere a un archivo gem, ya que este es el formato usado por las desarrolladoras Ruby cuando publican su software. El sistema de construcción desempaqueta el archivo gem, potencialmente parchea las fuentes, ejecuta la batería de pruebas, vuelve a empaquetar el archivo gem y lo instala. Adicionalmente, se puede hacer referencia a directorios y archivadores tar para permitir la construcción de archivos gem no publicados desde Git o un archivador tar de publicación de fuentes tradicional.

Se puede especificar el paquete Ruby usado mediante el parámetro #:ruby. Una lista de opciones adicionales pueden pasarse a la orden gem en el parámetro #:gem-flags.

Variable Scheme: waf-build-system

Esta variable se exporta en (guix build-system waf). Implementa un procedimiento de construcción alrededor del guión waf. Las fases comunes—configure, build y install—se implementan pasando sus nombres como parámetros al guión waf.

El guión waf es ejecutado por el intérprete Python. El paquete Python usado para la ejecución puede ser especificado con el parámetro #:python.

Variable Scheme: scons-build-system

Esta variable se exporta en (guix build-system scons). Implementa en procedimiento de construcción usado por la herramienta de construcción de software SCons. Este sistema de construcción ejecuta scons para construir el paquete, scons test para ejecutar las pruebas y después scons install para instalar el paquete.

Las opciones adicionales a pasar a scons se pueden especificar con el parámetro #:scons-flags. Los objetivos predeterminados de construcción (build) e instalación (install) pueden modificarse con #:build-targets y #:install-targets respectivamente. La versión de Python usada para ejecutar SCons puede especificarse seleccionando el paquete SCons apropiado con el parámetro #:scons.

Variable Scheme: haskell-build-system

Esta variable se exporta en (guix build-system haskell). Implementa el procedimiento de construcción Cabal usado por paquetes Haskell, el cual implica la ejecución de runhaskell Setup.hs configure --prefix=/gnu/store/… y runhaskell Setup.hs build. En vez de instalar el paquete ejecutando runhaskell Setup.hs install, para evitar el intento de registro de bibliotecas en el directorio de solo-lectura del compilador en el almacén, el sistema de construcción usa runhaskell Setup.hs copy, seguido de runhaskell Setup.hs register. Además, el sistema de construcción genera la documentación del paquete ejecutando runhaskell Setup.hs haddock, a menos que se pasase #:haddock? #f. Parámetros opcionales de Haddock pueden proporcionarse con la ayuda del parámetro #:haddock-flags. Si el archivo Setup.hs no es encontrado, el sistema de construcción busca Setup.lhs a su vez.

El compilador Haskell usado puede especificarse con el parámetro #:haskell cuyo valor predeterminado es ghc.

Variable Scheme: dub-build-system

Esta variable se exporta en (guix build-system dub). Implementa el procedimiento de construcción Dub usado por los paquetes D, que implica la ejecución de dub build y dub run. La instalación se lleva a cabo con la copia manual de los archivos.

El compilador D usado puede ser especificado con el parámetro #:ldc cuyo valor predeterminado es ldc.

Variable Scheme: emacs-build-system

Esta variable se exporta en (guix build-system emacs). Implementa un procedimiento de instalación similar al propio sistema de empaquetado de Emacs (see Packages in The GNU Emacs Manual).

Primero crea el archivo paquete-autoloads.el, tras lo que compila todos los archivos Emacs Lisp. De manera diferente al sistema de paquetes de Emacs, los archivos de documentación Info se mueven al directorio estándar de documentación y se borra el archivo dir. Los archivos del paquete Elisp se instalan directamente en share/emacs/site-lisp.

Variable Scheme: font-build-system

Esta variable se exporta en (guix build-system font). Implementa un procedimiento de instalación para paquetes de fuentes donde las proveedoras originales proporcionan archivos de tipografía TrueType, OpenType, etc. precompilados que simplemente necesitan copiarse en su lugar. Copia los archivos de tipografías a las localizaciones estándar en el directorio de salida.

Variable Scheme: meson-build-system

Esta variable se exporta en (guix build-system meson). Implementa el procedimiento de construcción para paquetes que usan Meson como su sistema de construcción.

It adds both Meson and Ninja to the set of inputs, and they can be changed with the parameters #:meson and #:ninja if needed.

Este sistema de construcción es una extensión de gnu-build-system, pero con las siguientes fases cambiadas por otras específicas para Meson:

configure

Esta fase ejecuta meson con las opciones especificadas en #:configure-flags. La opción --buildtype recibe el valor debugoptimized excepto cuando se especifique algo distinto en #:build-type.

build

Esta fase ejecuta ninja para construir el paquete en paralelo por defecto, pero esto puede cambiarse con #:parallel-build?.

check

The phase runs ‘meson test’ with a base set of options that cannot be overridden. This base set of options can be extended via the #:test-options argument, for example to select or skip a specific test suite.

install

Esta fase ejecuta ninja install y no puede cambiarse.

Aparte de estas, el sistema de ejecución también añade las siguientes fases:

fix-runpath

This phase ensures that all binaries can find the libraries they need. It searches for required libraries in subdirectories of the package being built, and adds those to RUNPATH where needed. It also removes references to libraries left over from the build phase by meson, such as test dependencies, that aren’t actually required for the program to run.

glib-or-gtk-wrap

Esta fase es la fase proporcionada por glib-or-gtk-build-system, y no está activa por defecto. Puede activarse con #:glib-or-gtk.

glib-or-gtk-compile-schemas

Esta fase es la fase proporcionada por glib-or-gtk-build-system, y no está activa por defecto. Puede activarse con #:glib-or-gtk.

Variable Scheme: linux-module-build-system

linux-module-build-system permite la construcción de módulos del núcleo Linux.

Este sistema de construcción es una extensión de gnu-build-system, pero con las siguientes fases cambiadas:

configure

Esta fase configura el entorno de modo que el Makefile del núcleo Linux pueda usarse para la construcción del módulo externo del núcleo.

build

Esta fase usa el Makefile del núcleo Linux para construir el módulo externo del núcleo.

install

Esta fase usa el Makefile del núcleo Linux para instalar el módulo externo del núcleo.

Es posible y útil especificar el núcleo Linux usado para la construcción del módulo (para ello debe usar el parámetro #:linux a través de la forma arguments en un paquete que use linux-module-build-system).

Variable Scheme: node-build-system

Esta variable se exporta en (guix build-system node). Implementa el procedimiento de construcción usado por Node.js, que implementa una aproximación de la orden npm install, seguida de una orden npm test.

El paquete Node.js usado para interpretar las órdenes npm puede especificarse a través del parámetro #:node cuyo valor predeterminado es node.

Por último, para paquetes que no necesiten nada tan sofisticado se proporciona un sistema de construcción “trivial”. Es trivial en el sentido de que no proporciona prácticamente funcionalidad: no incorpora entradas implícitas y no tiene una noción de fases de construcción.

Variable Scheme: trivial-build-system

Esta variable se exporta en (guix build-system trivial).

Este sistema de construcción necesita un parámetro #:builder. Este parámetro debe ser una expresión Scheme que construya la(s) salida(s) del paquete—como en build-expression->derivation (see build-expression->derivation).


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.6 Fases de construcción

Prácticamente todos los sistemas de construcción de paquetes implementan una noción de fases de construcción: una secuencia de acciones ejecutadas por el sistema de construcción, cuando usted construya el paquete, que conducen a la instalación de su producción en el almacén. Una excepción notable es el sistema de construcción trivial trivial-build-system (see Sistemas de construcción).

As discussed in the previous section, those build systems provide a standard list of phases. For gnu-build-system, the main build phases are the following:

set-paths

Define search path environment variables for all the input packages, including PATH (see Search Paths).

unpack

Extrae el archivador tar de la fuente, y cambia el directorio actual al directorio recién extraído. Si la fuente es realmente un directorio, lo copia al árbol de construcción y entra en ese directorio.

patch-source-shebangs

Sustituye secuencias “#!” encontradas al inicio de los archivos de fuentes para que hagan referencia a los nombres correctos de archivos del almacén. Por ejemplo, esto cambia #!/bin/sh por #!/gnu/store/…-bash-4.3/bin/sh.

configure

Ejecuta el guión configure con algunas opciones predeterminadas, como --prefix=/gnu/store/…, así como las opciones especificadas por el parámetro #:configure-flags.

build

Ejecuta make con la lista de opciones especificadas en #:make-flags. Si el parámetro #:parallel-build? es verdadero (por defecto), construye con make -j.

check

Ejecuta make check, u otro objetivo especificado con #:test-target, a menos que se pasase #:tests? #f. Si el parámetro #:parallel-tests? es verdadero (por defecto), ejecuta make check -j.

install

Ejecuta make install con las opciones enumeradas en #:make-flags.

patch-shebangs

Sustituye las secuencias “#!” en los archivos ejecutables instalados.

strip

Extrae los símbolos de depuración de archivos ELF (a menos que el valor de #:strip-binaries? sea falso), y los copia a la salida debug cuando esté disponible (see Instalación de archivos de depuración).

Other build systems have similar phases, with some variations. For example, cmake-build-system has same-named phases but its configure phases runs cmake instead of ./configure. Others, such as python-build-system, have a wholly different list of standard phases. All this code runs on the build side: it is evaluated when you actually build the package, in a dedicated build process spawned by the build daemon (see Invocación de guix-daemon).

Las fases de construcción se representan como listas asociativas o “alists” (see Association Lists in GNU Guile Reference Manual) donde cada clave es un símbolo que nombra a la fase y el valor asociado es un procedimiento que acepta un número arbitrario de parámetros. Por convención, estos procedimientos reciben información sobre la construcción en forma de parámetros que usan palabras clave, de los cuales pueden hacer uso o ignorarlos.

Por ejemplo, esta es la forma en la que (guix build gnu-build-system) define %standard-phases, la variable que contiene su lista asociativa de fases de construcción21:

;; Las fases de construcción de 'gnu-build-system'.

(define* (unpack #:key source #:allow-other-keys)
  ;; Extracción del archivador tar de las fuentes.
  (invoke "tar" "xvf" source))

(define* (configure #:key outputs #:allow-other-keys)
  ;; Ejecución del guión 'configure'. Instalación de la salida
  ;; en "out".
  (let ((out (assoc-ref outputs "out")))
    (invoke "./configure"
            (string-append "--prefix=" out))))

(define* (build #:allow-other-keys)
  ;; Compilación.
  (invoke "make"))

(define* (check #:key (test-target "check") (tests? #true)
                #:allow-other-keys)
  ;; Ejecución de la batería de pruebas.
  (if tests?
      (invoke "make" test-target)
      (display "test suite not run\n")))

(define* (install #:allow-other-keys)
  ;; Instalación de los archivos en el prefijo especificado
  ;; al guión 'configure'.
  (invoke "make" "install"))

(define %standard-phases
  ;; La lista de las fases estándar (algunas se omiten por
  ;; brevedad). Cada elemento es un par símbolo/procedimiento.
  (list (cons 'unpack unpack)
        (cons 'configure configure)
        (cons 'build build)
        (cons 'check check)
        (cons 'install install)))

Aquí se muestra como %standard-phases se define como una lista de pares símbolo/procedimiento (see Pairs in GNU Guile Reference Manual). El primer par asocia el procedimiento unpack con el símbolo unpack—un nombre; el segundo par define de manera similar la fase configure, etcétera. Cuando se construye un paquete que usa gnu-build-system, con su lista predeterminada de fases, estas fases se ejecutan de manera secuencial. Puede ver el nombre de cada fase a su inicio y tras su finalización en el registro de construcción de los paquetes que construya.

Echemos un vistazo a los propios procedimientos. Cada uno se define con define*: #:key enumera parámetros con palabras clave que el procedimiento acepta, con la posibilidad de proporcionar un valor predeterminado, y #:allow-other-keys especifica que se ignora cualquier otra palabra clave en los parámetros (see Optional Arguments in GNU Guile Reference Manual).

El procedimiento unpack utiliza el valor proporcionado al parámetro source, usado por el sistema de construcción usa para proporcionar el nombre de archivo del archivador de fuentes (o la copia de trabajo del sistema de control de versiones), e ignora otros parámetros. La fase configure únicamente tiene en cuenta el parámetro outputs, una lista asociativa de nombres de salida de paquetes con su nombre de archivo en el almacén (see Paquetes con múltiples salidas). Para ello se extrae el nombre de archivo de out, la salida predeterminada, y se lo proporciona a la orden ./configure como el prefijo de la instalación (./configure --prefix=out), lo que significa que make install acabará copiando todos los archivos en dicho directorio (see configuration and makefile conventions in GNU Coding Standards). Tanto build como install ignoran todos los parámetros. check utiliza el parámetro test-target, que especifica el nombre del objetivo del archivo Makefile que debe ejecutarse para ejecutar las pruebas; se imprime un mensaje y se omiten las pruebas cuando el parámetro tests? tiene falso como valor.

Se puede cambiar con el parámetro #:phases la lista de fases usada por el sistema de construcción para un paquete en particular. El cambio del conjunto de fases de construcción se realiza mediante la construcción de una nueva lista asociativa basada en la lista asociativa %standard-phases descrita previamente. Esto se puede llevar a cabo con procedimientos estándar para la manipulación de listas asociativas como alist-delete (see SRFI-1 Association Lists in GNU Guile Reference Manual); no obstante es más conveniente hacerlo con modify-phases (see modify-phases).

Aquí se encuentra un ejemplo de una definición de paquete que borra la fase configure de %standard-phases e inserta una nueva fase antes de la fase build, llamada proporciona-prefijo-en-makefile:

(define-public ejemplo
  (package
    (name "ejemplo")
    ;; se omiten otros campos
    (build-system gnu-build-system)
    (arguments
     '(#:phases (modify-phases %standard-phases
                  (delete 'configure)
                  (add-before 'build 'proporciona-prefijo-en-makefile
                    (lambda* (#:key outputs #:allow-other-keys)
                      ;; Modifica el archivo de make para que la
                      ;; variable 'PREFIX' apunte a "out".
                      (let ((out (assoc-ref outputs "out")))
                        (substitute* "Makefile"
                          (("PREFIX =.*")
                           (string-append "PREFIX = "
                                          out "\n")))
                        #true))))))))

La nueva fase insertada se escribe como un procedimiento anónimo, generado con lambda*; usa el parámetro outputs visto anteriormente. See Utilidades de construcción para obtener más información sobre las funciones auxiliares usadas en esta fase y donde encontrará más ejemplos de uso de modify-phases.

Tenga en cuenta que las fases de construcción son código que se evalúa cuando se realiza la construcción real del paquete. Esto explica por qué la expresión modify-phases al completo se encuentra escapada (viene precedida de ', un apóstrofe): se ha preparado para una ejecución posterior. See Expresiones-G para obener una explicación sobre esta preparación del código para las distintas fases de ejecución y los distintos estratos de código implicados.


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.7 Utilidades de construcción

En cuanto empiece a escribir definiciones de paquete no-triviales (see Definición de paquetes) u otras acciones de construcción (see Expresiones-G), es probable que empiece a buscar funciones auxiliares parecidas a las habituales en el intérprete de ordenes—creación de directorios, borrado y copia recursiva de archivos, manipulación de fases de construcción, etcétera. El módulo (guix build utils) proporciona dichos procedimientos auxiliares.

La mayoría de sistemas de construcción cargan (guix build utils) (see Sistemas de construcción). Por tanto, cuando construya fases de construcción personalizadas para sus definiciones de paquetes, habitualmente puede asumir que dichos procedimientos ya han sido incorporados al ámbito de ejecución.

Cuando escriba G-expressions, puede importar (guix build utils) en el “lado de la construcción” mediante el uso with-imported-modules e importandolos al ámbito actual con la forma sintáctica use-modules (see Using Guile Modules in GNU Guile Reference Manual):

(with-imported-modules '((guix build utils))  ; Se importa.
  (computed-file "empty-tree"
                 #~(begin
                     ;; Se añade al ámbito actual.
                     (use-modules (guix build utils))

                     ;; Se usa su procedimiento 'mkdir-p'.
                     (mkdir-p (string-append #$output "/a/b/c")))))

El resto de esta sección es la referencia de la mayoría de las procedimientos de utilidad proporcionados por (guix build utils).

8.7.1 Tratamiento de nombres de archivo del almacén

Esta sección documenta procedimientos para el manejo de nombres de archivo del almacén.

Procedimiento Scheme: %store-directory

Devuelve el nombre del directorio del almacén.

Procedimiento Scheme: store-file-name? archivo

Devuelve verdadero si archivo está en el almacén.

Procedimiento Scheme: strip-store-file-name archivo

Elimina /gnu/store y el hash de archivo, un nombre de archivo del almacén. El resultado es habitualmente una cadena "paquete-versión".

Procedimiento Scheme: package-name>name+version nombre

Cuando se proporciona nombre, un nombre de paquete como "foo-0.9.1b", devuelve dos valores: "foo" y "0.9.1b". Cuando la perte de la versión no está disponible, se devuelve nombre y #f. Se considera que el primer guión seguido de un dígito introduce la parte de la versión.

8.7.2 Tipos de archivo

Los siguientes procedimientos tratan con archivos y tipos de archivos.

Procedimiento Scheme: directory-exists? dir

Devuelve #t si dir existe y es un directorio.

Procedimiento Scheme: executable-file archivo

Devuelve #t si archivo existe y es ejecutable.

Devuelve #t si archivo es enlace simbólico (“symlink”).

Procedimiento Scheme: elf-file? archivo
Procedimiento Scheme: ar-file? archivo
Procedimiento Scheme: gzip-file? archivo

Devuelve #t si archivo es, respectivamente, un archivo ELF, un archivador ar (como una biblioteca estática .a), o un archivo comprimido con gzip.

Procedimiento Scheme: reset-gzip-timestamp archivo [#:keep-mtime? #t]

Si archivo es un archivo gzip, reinicia su marca de tiempo embebida (como con gzip --no-name) y devuelve un valor verdadero. En otro caso devuelve #f. Cuando keep-mtime? es verdadero, se preserva el tiempo de modificación del archivo.

8.7.3 Manipulación de archivos

Los siguientes procedimientos y macros sirven de ayuda en la creación, modificación y borrado de archivos. Proporcionan funcionalidades comparables con las herrambientas comunes del intérprete de órdenes como mkdir -p, cp -r, rm -r y sed. Sirven de complemento a la interfaz de sistema de archivos de Guile, la cual es extensa pero de bajo nivel (see POSIX in GNU Guile Reference Manual).

Sintaxis Scheme: with-directory-excursion directorio cuerpo

Ejecuta cuerpo con directorio como el directorio actual del proceso.

Esecialmente este macro cambia el directorio actual a directorio antes de evaluar cuerpo, usando chdir (see Processes in GNU Guile Reference Manual). Se vuelve al directorio inicial en cuanto se abandone el ámbito dinámico de cuerpo, ya sea a través de su finalización normal o de una salida no-local como pueda ser una excepción.

Procedimiento Scheme: mkdir-p dir

Crea el directorio dir y todos sus predecesores.

Procedimiento Scheme: install-file archivo directorio

Crea directorio si no existe y copia archivo allí con el mismo nombre.

Procedimiento Scheme: make-file-writable archivo

Activa el permiso de escritura en archivo para su propietaria.

Procedimiento Scheme: copy-recursively fuente destino [#:log (current-output-port)] [#:follow-symlinks? #f]  [#:copy-file

copy-file] [#:keep-mtime? #f] [#:keep-permissions? #t] Copy source directory to destination. Follow symlinks if follow-symlinks? is true; otherwise, just preserve them. Call copy-file to copy regular files. When keep-mtime? is true, keep the modification time of the files in source on those of destination. When keep-permissions? is true, preserve file permissions. Write verbose output to the log port.

Procedimiento Scheme: delete-file-recursively dir [#:follow-mounts? #f]

Borra dir recursivamente, como rm -rf, sin seguir los enlaces simbólicos. No atraviesa puntos de montaje tampoco, a no ser que follow-mounts? sea verdadero. Informa de los errores, pero no devuelve error por ellos.

Sintaxis Scheme: substitute archivo ((expreg var-encontrada…) cuerpo…) …

Sustituye expreg en archivo con la cadena que devuelve cuerpo. La evaluación de cuerpo se realiza con cada var-encontrada asociada con la subexpresión posicional correspondiente de la expresión regular. Por ejemplo:

(substitute* file
  (("hello")
   "good morning\n")
  (("foo([a-z]+)bar(.*)$" all letters end)
   (string-append "baz" letters end)))

En este ejemplo, cada ver que una línea de archivo contiene hola, esto se sustituye por buenos días. Cada vez que una línea del archivo corresponde con la segunda expresión regular, todo se asocia con la cadena encontrada al completo, letras toma el valor de la primera sub-expresión, y fin se asocia con la última.

Cuando una de las var-encontrada es _, no se asocia ninguna variable con la correspondiente subcadena.

También puede proporcionarse una lista como archivo, en cuyo caso los nombres de archivo que contenga serán los que se sometan a las sustituciones.

Tenga cuidado con el uso de $ para marcar el final de una línea; la cadena encontrada no contiene el caracter de salto de línea al final.

8.7.4 Búsqueda de archivos

Esta sección documenta procedimientos de búsqueda y filtrado de archivos.

Procedimiento Scheme: file-name-predicate expreg

Devuelve un predicado que devuelve un valor verdadero cuando el nombre del archivo proporcionado sin la parte del directorio corresponde con expreg.

Procedimiento Scheme: find-files dir [pred] [#:stat lstat] [#:directories? #f] [#:fail-on-error? #f]

Devuelve una lista ordenada lexicográficamente de los archivos que se encuentran en dir para los cuales pred devuelve verdadero. Se le proporcionan dos parámetros a pred: la ruta absoluta del archivo y su búfer de stat; el predicado predeteminado siempre devuelve verdadero. pred también puede ser una expresión regular, en cuyo caso es equivalente a escribir (file-name-predicate pred). stat se usa para obtener información del archivo; el uso de lstat significa que no se siguen los enlaces simbólicos. Si directories? es verdadero se incluyen también los directorios. Si fail-on-error? es verdadero, se emite una excepción en caso de error.

Aquí se pueden encontrar algunos ejemplos en los que se asume que el directorio actual es la raíz del arbol de fuentes de Guix:

;; Enumera todos los archivos regulares en el directorio actual.
(find-files ".")
 ("./.dir-locals.el" "./.gitignore" )

;; Enumera todos los archivos .scm en gnu/services.
(find-files "gnu/services" "\\.scm$")
 ("gnu/services/admin.scm" "gnu/services/audio.scm" )

;; Enumera los archivos ar en el directorio actual.
(find-files "." (lambda (file stat) (ar-file? file)))
 ("./libformat.a" "./libstore.a" )
Procedimiento Scheme: which programa

Devuelve el nombre de archivo completo para programa tal y como se encuentra en $PATH, o #f si no se ha encontrado programa.

Scheme Procedure: search-input-file inputs name
Scheme Procedure: search-input-directory inputs name

Return the complete file name for name as found in inputs; search-input-file searches for a regular file and search-input-directory searches for a directory. If name could not be found, an exception is raised.

Here, inputs must be an association list like inputs and native-inputs as available to build phases (see Fases de construcción).

Here is a (simplified) example of how search-input-file is used in a build phase of the wireguard-tools package:

(add-after 'install 'wrap-wg-quick
  (lambda* (#:key inputs outputs #:allow-other-keys)
    (let ((coreutils (string-append (assoc-ref inputs "coreutils")
                                    "/bin")))
      (wrap-program (search-input-file outputs "bin/wg-quick")
        #:sh (search-input-file inputs "bin/bash")
        `("PATH" ":" prefix ,(list coreutils))))))

8.7.5 Program Invocation

You’ll find handy procedures to spawn processes in this module, essentially convenient wrappers around Guile’s system* (see system* in GNU Guile Reference Manual).

Scheme Procedure: invoke program args

Invoke program with the given args. Raise an &invoke-error exception if the exit code is non-zero; otherwise return #t.

The advantage compared to system* is that you do not need to check the return value. This reduces boilerplate in shell-script-like snippets for instance in package build phases.

Scheme Procedure: invoke-error? c

Return true if c is an &invoke-error condition.

Scheme Procedure: invoke-error-program c
Scheme Procedure: invoke-error-arguments c
Scheme Procedure: invoke-error-exit-status c
Scheme Procedure: invoke-error-term-signal c
Scheme Procedure: invoke-error-stop-signal c

Access specific fields of c, an &invoke-error condition.

Scheme Procedure: report-invoke-error c [port]

Report to port (by default the current error port) about c, an &invoke-error condition, in a human-friendly way.

Typical usage would look like this:

(use-modules (srfi srfi-34) ;for 'guard'
             (guix build utils))

(guard (c ((invoke-error? c)
           (report-invoke-error c)))
  (invoke "date" "--imaginary-option"))

-| command "date" "--imaginary-option" failed with status 1
Scheme Procedure: invoke/quiet program args

Invoke program with args and capture program’s standard output and standard error. If program succeeds, print nothing and return the unspecified value; otherwise, raise a &message error condition that includes the status code and the output of program.

Here’s an example:

(use-modules (srfi srfi-34) ;for 'guard'
             (srfi srfi-35) ;for 'message-condition?'
             (guix build utils))

(guard (c ((message-condition? c)
           (display (condition-message c))))
  (invoke/quiet "date")  ;all is fine
  (invoke/quiet "date" "--imaginary-option"))

-| 'date --imaginary-option' exited with status 1; output follows:

    date: unrecognized option '--imaginary-option'
    Try 'date --help' for more information.

8.7.6 Fases de construcción

(guix build utils) también contiene herramientas para la manipulación de las fases de construcción usadas por los sistemas de construcción (see Sistemas de construcción). Las fases de construcción se representan como listas asociativas o “alists” (see Association Lists in GNU Guile Reference Manual) donde cada clave es un símbolo que nombra a la fase, y el valor asociado es un procedimiento (see Fases de construcción).

Tanto el propio Guile como el módulo (srfi srfi-1) proporcionan herramientas para la manipulación de listas asociativas. El módulo (guix build utils) complementa estas con herramientas pensadas para las fases de construcción.

Sintaxis Scheme: modify-phases fases cláusula

Modifica fases de manera secuencial com cada indique cada cláusula, que puede tener una de las siguentes formas:

(delete nombre-fase)
(replace nombre-fase nueva-fase)
(add-before nombre-fase nombre-nueva-fase nueva-fase)
(add-after nombre-fase nombre-nueva-fase nueva-fase)

Donde cada nombre-fase y nombre-nueva-fase es una expresión que evalúa aun símbolo, y nueva-fase es una expresión que evalúa a un procedimiento.

El siguiente ejemplo se ha tomado de la definición del paquete grep. Añade una fase que se ejecuta tras la fase install, llamada fix-egrep-and-fgrep. Dicha fase es un procedimiento (lambda* genera procedimientos anónimos) que toma un parámetro de palabra clave #:outputs e ignora el resto (see Optional Arguments in GNU Guile Reference Manual para obtener más información sobre lambda* y los parámetros opcionales y de palabras clave). La fase usa substitute* para modificar los guiones egrep y fgrep instalados para que hagan referencia a grep con su ruta de archivo absoluta:

(modify-phases %standard-phases
  (add-after 'install 'fix-egrep-and-fgrep
    ;; Patch 'egrep' and 'fgrep' to execute 'grep' via its
    ;; absolute file name instead of searching for it in $PATH.
    (lambda* (#:key outputs #:allow-other-keys)
      (let* ((out (assoc-ref outputs "out"))
             (bin (string-append out "/bin")))
        (substitute* (list (string-append bin "/egrep")
                           (string-append bin "/fgrep"))
          (("^exec grep")
           (string-append "exec " bin "/grep")))))))

En el siguiente ejemplo se modifican las fases de dos maneras: se elimina la fase estándar configure, posiblemente porque el paquete no tiene un guión configure ni nada similar, y la fase install predeterminada se sustituye por una que copia manualmente el archivo ejecutable que se debe instalar:

(modify-phases %standard-phases
  (delete 'configure)      ;no 'configure' script
  (replace 'install
    (lambda* (#:key outputs #:allow-other-keys)
      ;; The package's Makefile doesn't provide an "install"
      ;; rule so do it by ourselves.
      (let ((bin (string-append (assoc-ref outputs "out")
                                "/bin")))
        (install-file "footswitch" bin)
        (install-file "scythe" bin)))))

8.7.7 Wrappers

It is not unusual for a command to require certain environment variables to be set for proper functioning, typically search paths (see Search Paths). Failing to do that, the command might fail to find files or other commands it relies on, or it might pick the “wrong” ones—depending on the environment in which it runs. Examples include:

For a package writer, the goal is to make sure commands always work the same rather than depend on some external settings. One way to achieve that is to wrap commands in a thin script that sets those environment variables, thereby ensuring that those run-time dependencies are always found. The wrapper would be used to set PATH, GUILE_LOAD_PATH, or QT_PLUGIN_PATH in the examples above.

To ease that task, the (guix build utils) module provides a couple of helpers to wrap commands.

Scheme Procedure: wrap-program program [#:sh sh] [#:rest variables] Make a wrapper for program.

variables should look like this:

'(variable delimiter position list-of-directories)

where delimiter is optional. : will be used if delimiter is not given.

For example, this call:

(wrap-program "foo"
              '("PATH" ":" = ("/gnu/.../bar/bin"))
              '("CERT_PATH" suffix ("/gnu/.../baz/certs"
                                    "/qux/certs")))

will copy foo to .foo-real and create the file foo with the following contents:

#!location/of/bin/bash
export PATH="/gnu/.../bar/bin"
export CERT_PATH="$CERT_PATH${CERT_PATH:+:}/gnu/.../baz/certs:/qux/certs"
exec -a $0 location/of/.foo-real "$@"

If program has previously been wrapped by wrap-program, the wrapper is extended with definitions for variables. If it is not, sh will be used as the interpreter.

Scheme Procedure: wrap-script program [#:guile guile] [#:rest variables] Wrap the script program

such that variables are set first. The format of variables is the same as in the wrap-program procedure. This procedure differs from wrap-program in that it does not create a separate shell script. Instead, program is modified directly by prepending a Guile script, which is interpreted as a comment in the script’s language.

Special encoding comments as supported by Python are recreated on the second line.

Note that this procedure can only be used once per file as Guile scripts are not supported.


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.8 Search Paths

Many programs and libraries look for input data in a search path, a list of directories: shells like Bash look for executables in the command search path, a C compiler looks for .h files in its header search path, the Python interpreter looks for .py files in its search path, the spell checker has a search path for dictionaries, and so on.

Search paths can usually be defined or overridden via environment variables (see Environment Variables in The GNU C Library Reference Manual). For example, the search paths mentioned above can be changed by defining the PATH, C_INCLUDE_PATH, PYTHONPATH (or GUIX_PYTHONPATH), and DICPATH environment variables—you know, all these something-PATH variables that you need to get right or things “won’t be found”.

You may have noticed from the command line that Guix “knows” which search path environment variables should be defined, and how. When you install packages in your default profile, the file ~/.guix-profile/etc/profile is created, which you can “source” from the shell to set those variables. Likewise, if you ask guix shell to create an environment containing Python and NumPy, a Python library, and if you pass it the --search-paths option, it will tell you about PATH and GUIX_PYTHONPATH (see Invoking guix shell):

$ guix shell python python-numpy --pure --search-paths
export PATH="/gnu/store/…-profile/bin"
export GUIX_PYTHONPATH="/gnu/store/…-profile/lib/python3.9/site-packages"

When you omit --search-paths, it defines these environment variables right away, such that Python can readily find NumPy:

$ guix shell python python-numpy -- python3
Python 3.9.6 (default, Jan  1 1970, 00:00:01)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.version.version
'1.20.3'

For this to work, the definition of the python package declares the search path it cares about and its associated environment variable, GUIX_PYTHONPATH. It looks like this:

(package
  (name "python")
  (version "3.9.9")
  ;; some fields omitted...
  (native-search-paths
   (list (search-path-specification
          (variable "GUIX_PYTHONPATH")
          (files (list "lib/python/3.9/site-packages"))))))

What this native-search-paths field says is that, when the python package is used, the GUIX_PYTHONPATH environment variable must be defined to include all the lib/python/3.9/site-packages sub-directories encountered in its environment. (The native- bit means that, if we are in a cross-compilation environment, only native inputs may be added to the search path; see search-paths.) In the NumPy example above, the profile where python appears contains exactly one such sub-directory, and GUIX_PYTHONPATH is set to that. When there are several lib/python/3.9/site-packages—this is the case in package build environments—they are all added to GUIX_PYTHONPATH, separated by colons (:).

Nota: Notice that GUIX_PYTHONPATH is specified as part of the definition of the python package, and not as part of that of python-numpy. This is because this environment variable “belongs” to Python, not NumPy: Python actually reads the value of that variable and honors it.

Corollary: if you create a profile that does not contain python, GUIX_PYTHONPATH will not be defined, even if it contains packages that provide .py files:

$ guix shell python-numpy --search-paths --pure
export PATH="/gnu/store/…-profile/bin"

This makes a lot of sense if we look at this profile in isolation: no software in this profile would read GUIX_PYTHONPATH.

Of course, there are many variations on that theme: some packages honor more than one search path, some use separators other than colon, some accumulate several directories in their search path, and so on. A more complex example is the search path of libxml2: the value of the XML_CATALOG_FILES environment variable is space-separated, it must contain a list of catalog.xml files (not directories), which are to be found in xml sub-directories—nothing less. The search path specification looks like this:

(package
  (name "libxml2")
  ;; some fields omitted
  (native-search-paths
   (list (search-path-specification
          (variable "XML_CATALOG_FILES")
          (separator " ")
          (files '("xml"))
          (file-pattern "^catalog\\.xml$")
          (file-type 'regular)))))

Worry not, search path specifications are usually not this tricky.

The (guix search-paths) module defines the data type of search path specifications and a number of helper procedures. Below is the reference of search path specifications.

Data Type: search-path-specification

The data type for search path specifications.

variable

The name of the environment variable for this search path (a string).

files

The list of sub-directories (strings) that should be added to the search path.

separator (default: ":")

The string used to separate search path components.

As a special case, a separator value of #f specifies a “single-component search path”—in other words, a search path that cannot contain more than one element. This is useful in some cases, such as the SSL_CERT_DIR variable (honored by OpenSSL, cURL, and a few other packages) or the ASPELL_DICT_DIR variable (honored by the GNU Aspell spell checker), both of which must point to a single directory.

file-type (default: 'directory)

The type of file being matched—'directory or 'regular, though it can be any symbol returned by stat:type (see stat in GNU Guile Reference Manual).

In the libxml2 example above, we would match regular files; in the Python example, we would match directories.

file-pattern (default: #f)

This must be either #f or a regular expression specifying files to be matched within the sub-directories specified by the files field.

Again, the libxml2 example shows a situation where this is needed.

Some search paths are not tied by a single package but to many packages. To reduce duplications, some of them are pre-defined in (guix search-paths).

Scheme Variable: $SSL_CERT_DIR
Scheme Variable: $SSL_CERT_FILE

These two search paths indicate where X.509 certificates can be found (see Certificados X.509).

These pre-defined search paths can be used as in the following example:

(package
  (name "curl")
  ;; some fields omitted ...
  (native-search-paths (list $SSL_CERT_DIR $SSL_CERT_FILE)))

How do you turn search path specifications on one hand and a bunch of directories on the other hand in a set of environment variable definitions? That’s the job of evaluate-search-paths.

Scheme Procedure: evaluate-search-paths search-paths directories [getenv] Evaluate search-paths, a list of

search-path specifications, for directories, a list of directory names, and return a list of specification/value pairs. Use getenv to determine the current settings and report only settings not already effective.

The (guix profiles) provides a higher-level helper procedure, load-profile, that sets the environment variables of a profile.


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.9 El almacén

Conceptualmente, el almacén es el lugar donde se almacenan las derivaciones cuya construcción fue satisfactoria—por defecto, /gnu/store. Los subdirectorios en el almacén se denominan elementos del almacén o rutas del almacén en ocasiones. El almacén tiene una base de datos asociada que contiene información como las rutas del almacén a las que referencia cada ruta del almacén, y la lista de elementos válidos del almacén—los resultados de las construcciones satisfactorias. Esta base de datos reside en localstatedir/guix/db, donde localstatedir es el directorio de estado especificado vía --localstatedir en tiempo de configuración, normalmente /var.

El almacén siempre es accedido a través del daemon en delegación de sus clientes (see Invocación de guix-daemon). Para manipular el almacén, los clientes se conectan al daemon por un socket de dominio Unix, le envían peticiones y leen el resultado—esto son llamadas a procedimientos remotos, o RPC.

Nota: Las usuarias nunca deben modificar archivos directamente bajo el directorio /gnu/store. Esto llevaría a inconsistencias y rompería las premisas de inmutabilidad del modelo funcional de Guix (see Introducción).

See guix gc --verify, para información sobre cómo comprobar la integridad del almacén e intentar recuperarse de modificaciones accidentales.

El módulo (guix store) proporciona procedimientos para conectarse al daemon y realizar RPCs. Estos se describen más adelante. Por defecto, open-connection, y por tanto todas las órdenes guix, se conectan al daemon local o a la URI especificada en la variable de entorno GUIX_DAEMON_SOCKET.

Variable de entorno: GUIX_DAEMON_SOCKET

Cuando se ha definido, el valor de esta variable debe ser un nombre de archivo o una URI designando el punto de conexión del daemon. Cuando es un nombre de archivo, denota un socket de dominio Unix al que conectarse. Además de nombres de archivos, los esquemas de URI aceptados son:

file
unix

Estos son equivalentes a los sockets de dominio Unix. file:///var/guix/daemon-socket/socket es equivalente a /var/guix/daemon-socket/socket.

guix

Estas URI denotan conexiones sobre TCP/IP, sin cifrado ni verificación de la máquina remota. La URI debe especificar el nombre de máquina y opcionalmente un número de puerto (por defecto se usa el puerto 44146):

guix://principal.guix.example.org:1234

Esta configuración es apropiada para redes locales, como clusters, donde únicamente los nodos de confianza pueden conectarse al daemon de construcción en principal.guix.example.org.

La opción --listen de guix-daemon puede usarse para indicarle que escuche conexiones TCP (see --listen).

ssh

These URIs allow you to connect to a remote daemon over SSH. This feature requires Guile-SSH (see Requisitos) and a working guile binary in PATH on the destination machine. It supports public key and GSSAPI authentication. A typical URL might look like this:

ssh://carlos@guix.example.org:22

Como con guix copy, se tienen en cuenta los archivos habituales de configuración del cliente OpenSSH (see Invocación de guix copy).

Esquemas URI adicionales pueden ser aceptados en el futuro.

Nota: La conexión con daemon de construcción remotos se considera experimental en df72ba9. Por favor, contacte con nosotras para compartir cualquier problema o sugerencias que pueda tener (see Contribuir).

Procedimiento Scheme: open-connection [uri] [#:reserve-space? #t]

Abre una conexión al daemon a través del socket de dominio Unix apuntado por uri (una cadena). Cuando reserve-space? es verdadero, le indica que reserve un poco de espacio extra en el sistema de archivos de modo que el recolector de basura pueda operar incluso cuando el disco se llene. Devuelve un objeto servidor.

El valor por defecto de uri es %default-socket-path, que ese la ruta esperada según las opciones proporcionadas a configure.

Procedimiento Scheme: close-connection servidor

Cierra la conexión al servidor.

Variable Scheme: current-build-output-port

Esta variable está enlazada a un parámetro SRFI-39, que referencia al puerto donde los logs de construcción y error enviados por el daemon deben escribirse.

Los procedimientos que realizan RPCs toman todos como primer parámetro un objeto servidor.

Procedimiento Scheme: valid-path? servidor ruta

Devuelve #t cuando ruta designa un elemento válido del almacén y #f en otro caso (un elemento no-válido puede existir en el disco pero aun así no ser válido, por ejemplo debido a que es el resultado de una construcción que se interrumpió o falló).

Una condición &store-protocol-error se eleva si ruta no contiene como prefijo el directorio del almacén (/gnu/store).

Procedimiento Scheme: add-text-to-store servidor nombre texto [referencias]

Añade texto bajo el archivo nombre en el almacén, y devuelve su ruta en el almacén. referencias es la lista de rutas del almacén a las que hace referencia la ruta del almacén resultante.

Procedimiento Scheme: build-derivations almacén derivaciones [modo]

Construye derivaciones, una lista de objetos <derivation>, nombres de archivo .drv, o pares derivación/salida, usando el modo especificado—(build-mode normal) en caso de omisión.

Fíjese que el módulo (guix monads) proporciona una mónada así como versiones monádicas de los procedimientos previos, con el objetivo de hacer más conveniente el trabajo con código que accede al almacén (see La mónada del almacén).

Esta sección actualmente está incompleta.


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.10 Derivaciones

Las acciones de construcción a bajo nivel y el entorno en el que se realizan se representan mediante derivaciones. Una derivación contiene las siguientes piezas de información:

Las derivaciones permiten a los clientes del daemon comunicar acciones de construcción al almacén. Existen en dos formas: como una representación en memoria, tanto en el lado del cliente como el del daemon, y como archivos en el almacén cuyo nombre termina en .drv—estos archivos se conocen como rutas de derivación. Las rutas de derivación se pueden proporcionar al procedimiento build-derivations para que realice las acciones de construcción prescritas (see El almacén).

Operaciones como la descarga de archivos y las instantáneas de un control de versiones para las cuales el hash del contenido esperado se conoce previamente se modelan como derivaciones de salida fija. Al contrario que las derivaciones normales, las salidas de una derivación de salida fija son independientes de sus entradas—por ejemplo, la descarga del código fuente produce el mismo resultado independientemente del método de descarga y las herramientas usadas.

Las derivaciones de salida—es decir, los resultados de construcción—tienen un conjunto de referencias, del que informa la RPC references o la orden guix gc --references (see Invocación de guix gc). Las referencias son el conjunto de dependencias en tiempo de ejecución de los resultados de construcción. Las referencias son un subconjunto de las entradas de la derivación; el daemon de construcción calcula este subconjunto de forma automática mediante el procesado de todos los archivos en las salidas.

El módulo (guix derivations) proporciona una representación de derivaciones como objetos Scheme, junto a procedimientos para crear y manipular de otras formas derivaciones. La primitiva de más bajo nivel para crear una derivación es el procedimiento derivation:

Procedimiento Scheme: derivation almacén nombre constructor args [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] [#:recursive? #f] [#:inputs '()] [#:env-vars '()] [#:system (%current-system)] [#:references-graphs #f] [#:allowed-references #f] [#:disallowed-references #f] [#:leaked-env-vars #f] [#:local-build? #f] [#:substitutable? #t] [#:properties '()]

Construye una derivación con los parámetros proporcionados, y devuelve el objeto <derivation> resultante.

Cuando se proporcionan hash y hash-algo, una derivación de salida fija se crea—es decir, una cuyo resultado se conoce de antemano, como la descarga de un archivo. Si, además, recursive? es verdadero, entonces la salida fijada puede ser un archivo ejecutable o un directorio y hash debe ser el hash de un archivador que contenga esta salida.

Cuando references-graphs es verdadero, debe ser una lista de pares de nombre de archivo/ruta del almacén. En ese caso, el grafo de referencias de cada ruta del almacén se exporta en el entorno de construcción del archivo correspondiente, en un formato de texto simple.

Cuando allowed-references es verdadero, debe ser una lista de elementos del almacén o salidas a las que puede hacer referencia la salida de la derivación. Del mismo modo, disallowed-references, en caso de ser verdadero, debe ser una lista de cosas a las que las salidas no pueden hacer referencia.

Cuando leaked-env-vars es verdadero, debe ser una lista de cadenas que denoten variables de entorno que se permite “escapar” del entorno del daemon al entorno de construcción. Esto es únicamente aplicable a derivaciones de salida fija—es decir, cuando hash es verdadero. El uso principal es permitir que variables como http_proxy sean pasadas a las derivaciones que descargan archivos.

Cuando local-build? es verdadero, declara que la derivación no es una buena candidata para delegación y debe ser construida localmente (see Configuración de delegación del daemon). Este es el caso para pequeñas derivaciones donde los costes de transferencia de datos sobrepasarían los beneficios.

Cuando substitutable? es falso, declara que las sustituciones de la salida de la derivación no deben usarse (see Sustituciones). Esto es útil, por ejemplo, cuando se construyen paquetes que capturan detalles sobre el conjunto de instrucciones de la CPU anfitriona.

properties debe ser una lista asociada que describe “propiedades” de la derivación. Debe mantenerse tal cual, sin interpretar, en la derivación.

Esto es un ejemplo con un guión de shell como constructor, asumiendo que almacén es una conexión abierta al daemon, bash apunta al ejecutable Bash en el almacén:

(use-modules (guix utils)
             (guix store)
             (guix derivations))

(let ((constructor   ; añade el guión de Bash al almacén
        (add-text-to-store store "mi-constructor.sh"
                           "echo hola mundo > $out\n" '())))
  (derivation almacen "foo"
              bash `("-e" ,builder)
              #:inputs `((,bash) (,constructor))
              #:env-vars '(("HOME" . "/sindirectorio"))))
 #<derivation /gnu/store/…-foo.drv => /gnu/store/…-foo>

Como puede suponerse, el uso directo de esta primitiva es algo enrevesado. Una mejor aproximación es escribir guiones de construcción en Scheme, ¡por supuesto! La mejor forma de hacerlo es escribir el código de construcción como una “expresión-G”, y pasarla a gexp->derivation. Para más información, see Expresiones-G.

En otros tiempos, gexp->derivation no existía y la creación de derivaciones con código de construcción escrito en Scheme se conseguía con build-expression->derivation, documentada más adelante. Este procedimiento está ahora obsoleto en favor del procedimiento gexp->derivation mucho más conveniente.

Procedimiento Scheme: build-expression->derivation almacén nombre exp [#:system (%current-system)] [#:inputs '()] [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] [#:recursive? #f] [#:env-vars '()] [#:modules '()] [#:references-graphs #f] [#:allowed-references #f] [#:disallowed-references #f] [#:local-build? #f] [#:substitutable? #t] [#:guile-for-build #f]

Devuelve una derivación que ejecuta la expresión Scheme exp como un constructor para la derivación nombre. inputs debe ser una lista de tuplas (nombre ruta-drv sub-drv); cuando sub-drv se omite, se asume "out". modules es una lista de nombres de módulos Guile de la ruta actual de búsqueda a copiar en el almacén, compilados, y poner a disposición en la ruta de carga durante la ejecución de exp—por ejemplo, ((guix build utils) (guix build gnu-build-system)).

exp se evalúa en un entorno donde %outputs está asociada a una lista de pares salida/ruta, y donde %build-inputs está asociada a una lista de pares cadena/ruta-de-salida que provienen de inputs. De manera opcional, env-vars es una lista de pares de cadenas que especifican el nombre y el valor de las variables de entorno visibles al constructor. El constructor termina pasando el resultado de exp a exit; por tanto, cuando exp devuelve #f, la construcción se considera fallida.

exp se construye usando guile-for-build (una derivación). Cuando guile-for-build se omite o es #f, el valor del fluido %guile-for-build se usa en su lugar.

Véase el procedimiento derivation para el significado de references-graphs, allowed-references, disallowed-references, local-build? y substitutable?.

Aquí está un ejemplo de derivación de salida única que crea un directorio que contiene un archivo:

(let ((constructor '(let ((salida (assoc-ref %outputs "out")))
                      (mkdir salida)    ; crea /gnu/store/…-goo
                      (call-with-output-file (string-append salida "/prueba")
                        (lambda (p)
                          (display '(hola guix) p))))))
  (build-expression->derivation almacen "goo" constructor))

 #<derivation /gnu/store/…-goo.drv => …>

Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.11 La mónada del almacén

Los procedimientos que operan en el almacén descritos en la sección previa toman todos una conexión abierta al daemon de construcción en su primer parámetro. Aunque el modelo subyacente es funcional, tienen o bien efectos secundarios o dependen del estado actual del almacén.

Lo anterior es inconveniente: la conexión al daemon de construcción tiene que proporcionarse en todas estas funciones, haciendo imposible la composición de funciones que no toman ese parámetro con funciones que sí lo hacen. Lo último puede ser problemático: ya que las operaciones del almacén tienen efectos secundarios y/o dependen del estado externo, deben ser secuenciadas de manera adecuada.

Aquí es donde entra en juego el módulo (guix monads). Este módulo proporciona un entorno para trabajar con mónadas, y una mónada particularmente útil para nuestros usos, la mónada del almacén. Las mónadas son una construcción que permite dos cosas: asociar “contexto” con valores (en nuestro caso, el contexto es el almacén), y la construcción de secuencias de computaciones (aquí computaciones incluye accesos al almacén). Los valores en una mónada—valores que transportan este contexto adicional—se llaman valores monádicos; los procedimientos que devuelven dichos valores se llaman procedimientos monádicos.

Considere este procedimiento “normal”:

(define (enlace-sh almacen)
  ;; Devuelve una derivación que enlaza el ejecutable 'bash'.
  (let* ((drv (package-derivation store bash))
         (out (derivation->output-path drv))
         (sh  (string-append out "/bin/bash")))
    (build-expression->derivation store "sh"
                                  `(symlink ,sh %output))))

Mediante el uso de (guix monads) y (guix gexp), puede reescribirse como una función monádica:

(define (enlace-sh)
  ;; Lo mismo, pero devuelve un valor monádico.
  (mlet %store-monad ((drv (package->derivation bash)))
    (gexp->derivation "sh"
                      #~(symlink (string-append #$drv "/bin/bash")
                                 #$output))))

Hay varias cosas a tener en cuenta en la segunda versión: el parámetro store ahora es implícito y es “hilado en las llamadas a los procedimientos monádicos package->derivation y gexp->derivation, y el valor monádico devuelto por package->derivation es asociado mediante el uso de mlet en vez de un simple let.

Al final, la llamada a package->derivation puede omitirse ya que tendrá lugar implícitamente, como veremos más adelante (see Expresiones-G):

(define (enlace-sh)
  (gexp->derivation "sh"
                    #~(symlink (string-append #$bash "/bin/bash")
                               #$output)))

La ejecución del procedimiento monádico enlace-para-sh no tiene ningún efecto. Como alguien dijo una vez, “sales de una mónada como sales de un edificio en llamas: corriendo” (run en inglés). Por tanto, para salir de la mónada y obtener el efecto deseado se debe usar run-with-store:

(run-with-store (open-connection) (enlace-sh))
 /gnu/store/...-enlace-para-sh

Fíjese que el módulo (guix monad-repl) extiende la sesión interactiva de Guile con nuevas “meta-órdenes” para facilitar el trabajo con procedimientos monádicos: run-in-store y enter-store-monad. El primero se usa para “ejecutar” un valor monádico único a través del almacén:

scheme@(guile-user)> ,run-in-store (package->derivation hello)
$1 = #<derivation /gnu/store/…-hello-2.9.drv => …>

El último entra en un entorno interactivo recursivo, donde todos los valores devueltos se ejecutan automáticamente a través del almacén:

scheme@(guile-user)> ,enter-store-monad
store-monad@(guile-user) [1]> (package->derivation hello)
$2 = #<derivation /gnu/store/…-hello-2.9.drv => …>
store-monad@(guile-user) [1]> (text-file "foo" "Hello!")
$3 = "/gnu/store/…-foo"
store-monad@(guile-user) [1]> ,q
scheme@(guile-user)>

Fíjese que los valores no-monádicos no pueden devolverse en el entorno interactivo store-monad.

Las formas sintácticas principales para tratar con mónadas en general se proporcionan por el módulo (guix monads) y se describen a continuación.

Sintaxis Scheme: with-monad mónada cuerpo ...

Evalúa cualquier forma >>= o return en cuerpo como estando en mónada.

Sintaxis Scheme: return val

Devuelve el valor monádico que encapsula val.

Sintaxis Scheme: >>= mval mproc ...

Asocia el valor monádico mval, pasando su “contenido” a los procedimientos monádicos mproc22. Puede haber un mproc o varios, como en este ejemplo:

(run-with-state
    (with-monad %state-monad
      (>>= (return 1)
           (lambda (x) (return (+ 1 x)))
           (lambda (x) (return (* 2 x)))))
  'un-estado)

 4
 un-estado
Sintaxis Scheme: mlet mónada ((var mval) ...) cuerpo ...
Sintaxis Scheme: mlet* mónada ((var mval) ...) cuerpo ... Asocia las variables var a los valores monádicos

mval en cuerpo, el cual es una secuencia de expresiones. Como con el operador bind, esto puede pensarse como el “desempaquetado” del valor crudo no-monádico dentro del ámbito del cuerpo. La forma (var -> val) asocia var al valor “normal” val, como en let. Las operaciones de asociación ocurren en secuencia de izquierda a derecha. La última expresión de cuerpo debe ser una expresión monádica, y su resultado se convertirá en el resultado de mlet o mlet* cuando se ejecute en la mónada.

mlet* es a mlet lo que let* es a let (see Local Bindings in GNU Guile Reference Manual).

Sistema Scheme: mbegin mónada mexp ...

Asocia mexp y las siguientes expresiones monádicas en secuencia, devolviendo el resultado de la última expresión. Cada expresión en la secuencia debe ser una expresión monádica.

Esto es similar a mlet, excepto que los valores devueltos por las expresiones monádicas se ignoran. En ese sentido el funcionamiento es análogo a begin pero aplicado a expresiones monádicas.

Sistema Scheme: mwhen condición mexp0 mexp* ...

Cuando condición es verdadero, evalúa la secuencia de expresiones monádicas mexp0..mexp* como dentro de mbegin. Cuando condición es falso, devuelve *unespecified* en la mónada actual. Todas las expresiones en la secuencia deben ser expresiones monádicas.

Sistema Scheme: munless condición mexp0 mexp* ...

Cuando condición es falso, evalúa la secuencia de expresiones monádicas mexp0..mexp* como dentro de mbegin. Cuando condición es verdadero, devuelve *unespecified* en la mónada actual. Todas las expresiones en la secuencia deben ser expresiones monádicas.

El módulo (guix monads) proporciona la mónada de estado, que permite que un valor adicional—el estado—sea hilado a través de las llamadas a procedimientos monádicos.

Variable Scheme: %state-monad

La mónada de estado. Procedimientos en la mónada de estado pueden acceder y cambiar el estado hilado.

Considere el siguiente ejemplo. El procedimiento cuadrado devuelve un valor en la mónada de estado.

(define (cuadrado x)
  (mlet %state-monad ((count (current-state)))
    (mbegin %state-monad
      (set-current-state (+ 1 count))
      (return (* x x)))))

(run-with-state (sequence %state-monad (map cuadrado (iota 3))) 0)
 (0 1 4)
 3

Cuando se “ejecuta” a través de %state-monad, obtenemos un valor adicional de estado, que es el número de llamadas a cuadrado.

Procedimiento monádico: current-state

Devuelve el estado actual como un valor monádico.

Procedimiento monádico: set-current-state valor

Establece el estado actual a valor y devuelve el estado previo como un valor monádico.

Procedimiento monádico: state-push valor

Apila valor al estado actual, que se asume que es una lista, y devuelve el estado previo como un valor monádico.

Procedimiento monádico: state-pop

Extrae un valor del estado actual y lo devuelve como un valor monádico. Se asume que el estado es una lista.

Procedimiento Scheme: run-with-state mval [estado]

Ejecuta un valor monádico mval comenzando con estado como el estado inicial. Devuelve dos valores: el valor resultante y el estado resultante.

La interfaz principal a la mónada del almacén, proporcionada por el módulo (guix store), es como sigue.

Variable Scheme: %store-monad

La mónada del almacén—un alias para %state-monad.

Los valores en la mónada del almacén encapsulan los accesos al almacén. Cuando su efecto es necesario, un valor de la mónada del almacén será “evaluado” cuando se proporcione al procedimiento run-with-store (véase a continuación).

Procedimiento Scheme: run-with-store almacén mval [#:guile-for-build] [#:system (%current-system)]

Ejecuta mval, un valor monádico en la mónada del almacén, en almacén, una conexión abierta al almacén.

Procedimiento monádico: text-file nombre texto [referencias]

Devuelve como un valor monádico el nombre absoluto del archivo en el almacén del archivo que contiene ŧexto, una cadena. referencias es una lista de elementos del almacén a los que el archivo de texto referencia; su valor predeterminado es la lista vacía.

Procedimiento monádico: binary-file nombre datos [referencias]

Devuelve como un valor monádico el nombre absoluto del archivo en el almacén del archivo que contiene datos, un vector de bytes. referencias es una lista de elementos del almacén a los que el archivo binario referencia; su valor predeterminado es la lista vacía.

Procedimiento monádico: interned-file archivo [nombre] [#:recursive? #t] [#:select? (const #t)]

Devuelve el nombre del archivo una vez internado en el almacén. Usa nombre como su nombre del almacén, o el nombre base de archivo si nombre se omite.

Cuando recursive? es verdadero, los contenidos del archivo se añaden recursivamente; si archivo designa un archivo plano y recursive? es verdadero, sus contenidos se añaden, y sus bits de permisos se mantienen.

Cuando recursive? es verdadero, llama a (select? archivo stat) por cada entrada del directorio, donde archivo es el nombre absoluto de archivo de la entrada y stat es el resultado de lstat; excluyendo las entradas para las cuales select? no devuelve verdadero.

El ejemplo siguiente añade un archivo al almacén, bajo dos nombres diferentes:

(run-with-store (open-connection)
  (mlet %store-monad ((a (interned-file "README"))
                      (b (interned-file "README" "LEGU-MIN")))
    (return (list a b))))

 ("/gnu/store/rwm…-README" "/gnu/store/44i…-LEGU-MIN")

El módulo (guix packages) exporta los siguientes procedimientos monádicos relacionados con paquetes:

Procedimiento monádico: package-file paquete [archivo] [#:system (%current-system)] [#:target #f] [#:output "out"]

Devuelve como un valor monádico el nombre absoluto de archivo de archivo dentro del directorio de salida output del paquete. Cuando se omite archivo, devuelve el nombre del directorio de salida output del paquete. Cuando target es verdadero, se usa como una tripleta de compilación cruzada.

Tenga en cuenta que este procedimiento no construye paquete. Por lo tanto, el resultado puede designar o no un archivo existente. Le recomendamos que no use este procedimiento a no ser que sepa qué está haciendo.

Procedimiento monádico: package->derivation paquete [sistema]
Procedimiento monádico: package->cross-derivation paquete objetivo [sistema]

Versión monádica de package-derivation y package-cross-derivation (see Definición de paquetes).


Next: , Previous: , Up: Interfaz programática   [Contents][Index]

8.12 Expresiones-G

Por tanto tenemos “derivaciones”, que representan una secuencia de acciones de construcción a realizar para producir un elemento en el almacén (see Derivaciones). Estas acciones de construcción se llevan a cabo cuando se solicita al daemon construir realmente la derivación; se ejecutan por el daemon en un contenedor (see Invocación de guix-daemon).

No debería ser ninguna sorpresa que nos guste escribir estas acciones de construcción en Scheme. Cuando lo hacemos, terminamos con dos estratos de código Scheme23: el “código anfitrión”—código que define paquetes, habla al daemon, etc.—y el “código de construcción”—código que realmente realiza las acciones de construcción, como la creación de directorios, la invocación de make, etcétera (see Fases de construcción).

Para describir una derivación y sus acciones de construcción, típicamente se necesita embeber código de construcción dentro del código anfitrión. Se resume en la manipulación de código de construcción como datos, y la homoiconicidad de Scheme—el código tiene representación directa como datos—es útil para ello. Pero necesitamos más que el mecanismo normal de quasiquote en Scheme para construir expresiones de construcción.

El módulo (guix gexp) implementa las expresiones-G, una forma de expresiones-S adaptada para expresiones de construcción. Las expresiones-G, o gexps, consiste esencialmente en tres formas sintácticas: gexp, ungexp y ungexp-splicing (o simplemente: #~, #$ y #$@), que son comparables a quasiquote, unquote y unquote-splicing, respectivamente (see quasiquote in GNU Guile Reference Manual). No obstante, hay importantes diferencias:

Este mecanismo no se limita a objetos de paquete ni derivación: pueden definirse compiladores capaces de “bajar el nivel” de otros objetos de alto nivel a derivaciones o archivos en el almacén, de modo que esos objetos puedan introducirse también en expresiones-G. Por ejemplo, un tipo útil de objetos de alto nivel que pueden insertarse en una expresión-G son los “objetos tipo-archivo”, los cuales facilitan la adición de archivos al almacén y su referencia en derivaciones y demás (vea local-file y plain-file más adelante).

Para ilustrar la idea, aquí está un ejemplo de expresión-G:

(define exp-construccion
  #~(begin
      (mkdir #$output)
      (chdir #$output)
      (symlink (string-append #$coreutils "/bin/ls")
               "enumera-archivos")))

Esta expresión-G puede pasarse a gexp->derivation; obtenemos una derivación que construye un directorio que contiene exactamente un enlace simbólico a /gnu/store/…-coreutils-8.22/bin/ls:

(gexp->derivation "la-cosa" exp-construccion)

Como se puede esperar, la cadena "/gnu/store/…-coreutils-8.22" se sustituye por la referencia al paquete coreutils en el código de construcción real, y coreutils se marca automáticamente como una entrada a la derivación. Del mismo modo, #$output (equivalente a (ungexp output)) se reemplaza por una cadena que contiene el nombre del directorio de la salida de la derivación.

En un contexto de compilación cruzada, es útil distinguir entre referencias a construcciones nativas del paquete—que pueden ejecutarse en el sistema anfitrión—de referencias de compilaciones cruzadas de un paquete. Para dicho fin, #+ tiene el mismo papel que #$, pero es una referencia a una construcción nativa del paquete:

(gexp->derivation "vi"
   #~(begin
       (mkdir #$output)
       (mkdir (string-append #$output "/bin"))
       (system* (string-append #+coreutils "/bin/ln")
                "-s"
                (string-append #$emacs "/bin/emacs")
                (string-append #$output "/bin/vi")))
   #:target "aarch64-linux-gnu")

En el ejemplo previo, se usa la construcción nativa de coreutils, de modo que ln pueda realmente ejecutarse en el anfitrión; pero se hace referencia a la construcción de compilación cruzada de emacs.

Otra característica de las expresiones-G son los módulos importados: a veces deseará ser capaz de usar determinados módulos Guile del “entorno anfitrión” en la expresión-G, de modo que esos módulos deban ser importados en el “entorno de construcción”. La forma with-imported-modules le permite expresarlo:

(let ((build (with-imported-modules '((guix build utils))
               #~(begin
                   (use-modules (guix build utils))
                   (mkdir-p (string-append #$output "/bin"))))))
  (gexp->derivation "directorio-vacio"
                    #~(begin
                        #$build
                        (display "éxito!\n")
                        #t)))

En este ejemplo, el módulo (guix build utils) se incorpora automáticamente dentro del entorno de construcción aislado de nuestra expresión-G, de modo que (use-modules (guix build utils)) funciona como se espera.

De manera habitual deseará que la clausura del módulo se importe—es decir, el módulo en sí y todos los módulos de los que depende—en vez del módulo únicamente; si no se hace, cualquier intento de uso del módulo fallará porque faltan módulos dependientes. El procedimiento source-module-closure computa la clausura de un módulo mirando en las cabeceras de sus archivos de fuentes, lo que es útil en este caso:

(use-modules (guix modules))   ;para 'source-module-closure'

(with-imported-modules (source-module-closure
                         '((guix build utils)
                           (gnu build image)))
  (gexp->derivation "something-with-vms"
                    #~(begin
                        (use-modules (guix build utils)
                                     (gnu build image))
                        )))

De la misma manera, a veces deseará importar no únicamente módulos puros de Scheme, pero también “extensiones” como enlaces Guile a bibliotecas C u otros paquetes “completos”. Si, digamos, necesitase el paquete guile-json disponible en el lado de construcción, esta sería la forma de hacerlo:

(use-modules (gnu packages guile))  ;para 'guile-json'

(with-extensions (list guile-json)
  (gexp->derivation "algo-con-json"
                    #~(begin
                        (use-modules (json))
                        )))

La forma sintáctica para construir expresiones-G se resume a continuación.

Sintaxis Scheme: #~exp
Sintaxis Scheme: (gexp exp)

Devuelve una expresión-G que contiene exp. exp puede contener una o más de las siguientes formas:

#$obj
(ungexp obj)

Introduce una referencia a obj. obj puede tener uno de los tipos permitidos, por ejemplo un paquete o derivación, en cuyo caso la forma ungexp se substituye por el nombre de archivo de su salida—por ejemplo, "/gnu/store/…-coreutils-8.22.

Si obj es una lista, se recorre y las referencias a objetos permitidos se substituyen de manera similar.

Si obj es otra expresión-G, su contenido se inserta y sus dependencias se añaden a aquellas de la expresión-G que la contiene.

Si obj es otro tipo de objeto, se inserta tal cual es.

#$obj:salida
(ungexp obj salida)

Como la forma previa, pero referenciando explícitamente la salida de obj—esto es útil cuando obj produce múltiples salidas (see Paquetes con múltiples salidas).

#+obj
#+obj:salida
(ungexp-native obj)
(ungexp-native obj salida)

Igual que ungexp, pero produce una referencia a la construcción nativa de obj cuando se usa en un contexto de compilación cruzada.

#$output[:salida]
(ungexp output [salida])

Inserta una referencia a la salida de la derivación salida, o a la salida principal cuando salida se omite.

Esto únicamente tiene sentido para expresiones-G pasadas a gexp->derivation.

#$@lst
(ungexp-splicing lst)

Lo mismo que la forma previa, pero expande el contenido de la lista lst como parte de la lista que la contiene.

#+@lst
(ungexp-native-splicing lst)

Lo mismo que la forma previa, pero hace referencia a las construcciones nativas de los objetos listados en lst.

Las expresiones-G creadas por gexp o #~ son objetos del tipo gexp? en tiempo de ejecución (véase a continuación).

Sintaxis Scheme: with-imported-modules módulos cuerpo

Marca las expresiones-G definidas en el cuerpo… como si requiriesen módulos en su entorno de ejecución.

Cada elemento en módulos puede ser el nombre de un módulo, como (guix build utils), o puede ser el nombre de un módulo, seguido de una flecha, seguido de un objeto tipo-archivo:

`((guix build utils)
  (guix gcrypt)
  ((guix config) => ,(scheme-file "config.scm"
                                  #~(define-module ))))

En el ejemplo previo, los dos primeros módulos se toman de la ruta de búsqueda, y el último se crea desde el objeto tipo-archivo proporcionado.

Esta forma tiene ámbito léxico: tiene efecto en las expresiones-G definidas en cuerpo…, pero no en aquellas definidas, digamos, en procedimientos llamados por cuerpo….

Sintaxis Scheme: with-extensions extensiones cuerpo

Marca que las expresiones definidas en cuerpo… requieren extensiones en su entorno de construcción y ejecución. extensiones es típicamente una lista de objetos de paquetes como los que se definen en el módulo (gnu packages guile).

De manera concreta, los paquetes listados en extensiones se añaden a la ruta de carga mientras se compilan los módulos importados en cuerpo…; también se añaden a la ruta de carga en la expresión-G devuelta por cuerpo….

Procedimiento Scheme: gexp? obj

Devuelve #t si obj es una expresión-G.

Las expresiones-G están destinadas a escribirse en disco, tanto en código que construye alguna derivación, como en archivos planos en el almacén. Los procedimientos monádicos siguientes le permiten hacerlo (see La mónada del almacén, para más información sobre mónadas).

Procedimiento monádico: gexp->derivation nombre exp [#:system (%current-system)] [#:target #f] [#:graft? #t] [#:hash #f] [#:hash-algo #f] [#:recursive? #f] [#:env-vars '()] [#:modules '()] [#:module-path %load-path] [#:effective-version "2.2"] [#:references-graphs #f] [#:allowed-references #f] [#:disallowed-references #f] [#:leaked-env-vars #f] [#:script-name (string-append nombre "-builder")] [#:deprecation-warnings #f] [#:local-build? #f] [#:substitutable? #t] [#:properties '()] [#:guile-for-build #f]

Devuelve una derivación nombre que ejecuta exp (una expresión-G) con guile-for-build (una derivación) en el sistema system; exp se almacena en un archivo llamado script-name. Cuando target tiene valor verdadero, se usa como tripleta de compilación cruzada para paquetes a los que haga referencia exp.

modules está obsoleto en favor de with-imported-modules. Su significado es hacer que los módulos modules estén disponibles en el contexto de evaluación de exp; modules es una lista de nombres de módulos Guile buscados en module-path para ser copiados al almacén, compilados y disponibles en la ruta de carga durante la ejecución de exp—por ejemplo, ((guix build utils) (gui build gnu-build-system)).

effective-version determina la cadena usada cuando se añaden las extensiones de exp (vea with-extensions) a la ruta de búsqueda—por ejemplo, "2.2".

graft? determina si los paquetes a los que exp hace referencia deben ser injertados cuando sea posible.

Cuando references-graphs es verdadero, debe ser una lista de tuplas de una de las formas siguientes:

(nombre-archivo paquete)
(nombre-archivo paquete salida)
(nombre-archivo derivación)
(nombre-archivo derivación salida)
(nombre-archivo elemento-almacén)

El lado derecho de cada elemento de references-graphs se convierte automáticamente en una entrada del proceso de construcción de exp. En el entorno de construcción, cada nombre-archivo contiene el grafo de referencias del elemento correspondiente, en un formato de texto simple.

allowed-references debe ser o bien #f o una lista de nombres y paquetes de salida. En el último caso, la lista denota elementos del almacén a los que el resultado puede hacer referencia. Cualquier referencia a otro elemento del almacén produce un error de construcción. De igual manera con disallowed-references, que enumera elementos a los que las salidas no deben hacer referencia.

deprecation-warnings determina si mostrar avisos de obsolescencia durante la compilación de los módulos. Puede ser #f, #t o 'detailed.

El resto de parámetros funcionan como en derivation (see Derivaciones).

Los procedimientos local-file, plain-file, computed-file, program-file y scheme-file a continuación devuelven objetos tipo-archivo. Esto es, cuando se expanden en una expresión-G, estos objetos dirigen a un archivo en el almacén. Considere esta expresión-G:

#~(system* #$(file-append glibc "/sbin/nscd") "-f"
           #$(local-file "/tmp/mi-nscd.conf"))

El efecto aquí es el “internamiento” de /tmp/mi-nscd.conf mediante su copia al almacén. Una vez expandida, por ejemplo vía gexp->derivation, la expresión-G hace referencia a la copia bajo /gnu/store; por tanto, la modificación o el borrado del archivo en /tmp no tiene ningún efecto en lo que la expresión-G hace. plain-file puede usarse de manera similar; se diferencia en que el contenido del archivo se proporciona directamente como una cadena.

Procedimiento Scheme: local-file archivo [nombre] [#:recursive? #f] [#:select? (const #t)]

Devuelve un objeto que representa el archivo local archivo a añadir al almacén; este objeto puede usarse en una expresión-G. Si archivo es un nombre de archivo relativo, se busca de forma relativa al archivo fuente donde esta forma aparece; si archivo no es una cadena literal, se buscará de manera relativa al directorio de trabajo durante la ejecución. archivo se añadirá al almacén bajo nombre—de manera predeterminada el nombre de archivo sin los directorios.

Cuando recursive? es verdadero, los contenidos del archivo se añaden recursivamente; si archivo designa un archivo plano y recursive? es verdadero, sus contenidos se añaden, y sus bits de permisos se mantienen.

Cuando recursive? es verdadero, llama a (select? archivo stat) por cada entrada del directorio, donde archivo es el nombre absoluto de archivo de la entrada y stat es el resultado de lstat; excluyendo las entradas para las cuales select? no devuelve verdadero.

Esta es la contraparte declarativa del procedimiento monádico interned-file (see interned-file).

Procedimiento Scheme: plain-file nombre contenido

Devuelve un objeto que representa un archivo de texto llamado nombre con el contenido proporcionado (una cadena o un vector de bytes) para ser añadido al almacén.

Esta es la contraparte declarativa de text-file.

Procedimiento Scheme: computed-file nombre gexp [#:local-build? #t] [#:options '()]

Devuelve un objeto que representa el elemento del almacén nombre, un archivo o un directorio computado por gexp. Cuando local-build? tiene valor verdadero (el caso predeterminado), la derivación se construye de manera local. options es una lista de parámetros adicionales proporcionados a gexp->derivation.

Esta es la contraparte declarativa de gexp->derivation.

Procedimiento monádico: gexp->script nombre exp [#:guile (default-guile)] [#:module-path %load-path]  [#:system

(%current-system)] [#:target #f] Devuelve un guión ejecutable nombre que ejecuta exp usando guile, con los módulos importados por exp en su ruta de búsqueda. Busca los módulos de exp en module-path.

El ejemplo siguiente construye un guión que simplemente invoca la orden ls:

(use-modules (guix gexp) (gnu packages base))

(gexp->script "enumera-archivos"
              #~(execl #$(file-append coreutils "/bin/ls")
                       "ls"))

Cuando se ejecuta a través del almacén (see run-with-store), obtenemos una derivación que produce un archivo ejecutable /gnu/store/…-enumera-archivos más o menos así:

#!/gnu/store/…-guile-2.0.11/bin/guile -ds
!#
(execl "/gnu/store/…-coreutils-8.22"/bin/ls" "ls")
Procedimiento Scheme: program-file nombre exp [#:guile #f] [#:module-path %load-path]

Devuelve un objeto que representa el elemento ejecutable del almacén nombre que ejecuta gexp. guile es el paquete Guile usado para ejecutar el guión. Los módulos importados por gexp se buscan en module-path.

Esta es la contraparte declarativa de gexp->script.

Procedimiento monádico: gexp->file nombre exp [#:set-load-path? #t] [#:module-path %load-path] [#:splice? #f] [#:guile (default-guile)]

Devuelve una derivación que construye un archivo nombre que contiene exp. Cuando splice? es verdadero, se considera que exp es una lista de expresiones que deben ser expandidas en el archivo resultante.

Cuando set-load-path es verdadero, emite código en el archivo resultante para establecer %load-path y %load-compiled-path de manera que respeten los módulos importados por exp. Busca los módulos de exp en module-path.

El archivo resultante hace referencia a todas las dependencias de exp o a un subconjunto de ellas.

Procedimiento Scheme: scheme-file nombre exp [#:splice? #f] [#:set-load-path? #t]

Devuelve un objeto que representa el archivo Scheme nombre que contiene exp.

Esta es la contraparte declarativa de gexp->file.

Procedimiento monádico: text-file* nombre texto

Devuelve como un valor monádico una derivación que construye un archivo de texto que contiene todo texto. texto puede ser una lista de, además de cadenas, objetos de cualquier tipo que pueda ser usado en expresiones-G: paquetes, derivaciones, archivos locales, objetos, etc. El archivo del almacén resultante hace referencia a todos ellos.

Esta variante debe preferirse sobre text-file cuando el archivo a crear haga referencia a elementos del almacén. Esto es el caso típico cuando se construye un archivo de configuración que embebe nombres de archivos del almacén, como este:

(define (perfil.sh)
  ;; Devuelve el nombre de un guión shell en el almacén
  ;; que establece la variable de entorno 'PATH'
  (text-file* "perfil.sh"
              "export PATH=" coreutils "/bin:"
              grep "/bin:" sed "/bin\n"))

En este ejemplo, el archivo /gnu/store/…-perfil.sh resultante hará referencia a coreutils, grep y sed, por tanto evitando que se recolecten como basura durante su tiempo de vida.

Procedimiento Scheme: mixed-text-file nombre texto

Devuelve un objeto que representa el archivo del almacén nombre que contiene texto. texto es una secuencia de cadenas y objetos tipo-archivo, como en:

(mixed-text-file "perfil"
                 "export PATH=" coreutils "/bin:" grep "/bin")

Esta es la contraparte declarativa de text-file*.

Procedimiento Scheme: file-union nombre archivos

Devuelve un <computed-file> que construye un directorio que contiene todos los archivos. Cada elemento en archivos debe ser una lista de dos elementos donde el primer elemento es el nombre de archivo usado en el nuevo directorio y el segundo elemento es una expresión-G que denota el archivo de destino. Aquí está un ejemplo:

(file-union "etc"
            `(("hosts" ,(plain-file "hosts"
                                    "127.0.0.1 localhost"))
              ("bashrc" ,(plain-file "bashrc"
                                     "alias ls='ls --color=auto'"))))

Esto emite un directorio etc que contiene estos dos archivos.

Procedimiento Scheme: directory-union nombre cosas

Devuelve un directorio que es la unión de cosas, donde cosas es una lista de objetos tipo-archivo que denotan directorios. Por ejemplo:

(directory-union "guile+emacs" (list guile emacs))

emite un directorio que es la unión de los paquetes guile y emacs.

Procedimientos Scheme: file-append obj sufijo

Devuelve un objeto tipo-archivo que se expande a la concatenación de obj y sufijo, donde obj es un objeto que se puede bajar de nivel y cada sufijo es una cadena.

Como un ejemplo, considere esta expresión-G:

(gexp->script "ejecuta-uname"
              #~(system* #$(file-append coreutils
                                        "/bin/uname")))

El mismo efecto podría conseguirse con:

(gexp->script "ejecuta-uname"
              #~(system* (string-append #$coreutils
                                        "/bin/uname")))

Hay una diferencia no obstante: en el caso de file-append, el guión resultante contiene una ruta absoluta de archivo como una cadena, mientras que en el segundo caso, el guión resultante contiene una expresión (string-append …) para construir el nombre de archivo en tiempo de ejecución.

Sintaxis Scheme: let-system sistema cuerpo
Sintaxis Scheme: let-system (sistema objetivo) cuerpo

Asocia sistema al sistema objetivo actual—por ejemplo, "x86_64-linux"—dentro de cuerpo.

En el segundo caso, asocia también objetivo al objetivo actual de compilación cruzada—una tripleta de GNU como "arm-linux-gnueabihf"—o #f si no se trata de una compilación cruzada.

let-system es útil en el caso ocasional en el que el objeto introducido en la expresión-G depende del sistema objetivo, como en este ejemplo:

#~(system*
   #+(let-system system
       (cond ((string-prefix? "armhf-" system)
              (file-append qemu "/bin/qemu-system-arm"))
             ((string-prefix? "x86_64-" system)
              (file-append qemu "/bin/qemu-system-x86_64"))
             (else
              (error "¡ni idea!"))))
   "-net" "user" #$image)
Sintaxis Scheme: with-parameters ((parámetro valor …) exp

Este macro es similar a la forma parameterize para parámetros asociados de forma dinámica (see Parameters in GNU Guile Reference Manual). La principal diferencia es que se hace efectivo cuando el objeto tipo-archivo devuelto por exp se baja de nivel a una derivación o un elemento del almacén.

Un uso típico de with-parameters es para forzar el sistema efectivo de cierto objeto:

(with-parameters ((%current-system "i686-linux"))
  coreutils)

El ejemplo previo devuelve un objeto que corresponde a la construcción en i686 de Coreutils, independientemente del valor actual de %current-system.

Por supuesto, además de expresiones-G embebidas en código “anfitrión”, hay también módulos que contienen herramientas de construcción. Para clarificar que están destinados para su uso en el estrato de construcción, estos módulos se mantienen en el espacio de nombres (guix build …).

Internamente, los objetos de alto nivel se bajan de nivel, usando su compilador, a derivaciones o elementos del almacén. Por ejemplo, bajar de nivel un paquete emite una derivación, y bajar de nivel un plain-file emite un elemento del almacén. Esto se consigue usando el procedimiento monádico lower-object.

Procedimiento monádico: lower-object obj [sistema] [#:target #f]

Devuelve como un valor en %store-monad la derivación o elemento del almacén que corresponde a obj en sistema, compilando de manera cruzada para target si target es verdadero. obj debe ser un objeto que tiene asociado un compilador de expresiones-G, como por ejemplo un objeto del tipo <package>.

Procedure: gexp->approximate-sexp gexp

Sometimes, it may be useful to convert a G-exp into a S-exp. For example, some linters (see Invocación de guix lint) peek into the build phases of a package to detect potential problems. This conversion can be achieved with this procedure. However, some information can be lost in the process. More specifically, lowerable objects will be silently replaced with some arbitrary object – currently the list (*approximate*), but this may change.


Previous: , Up: Interfaz programática   [Contents][Index]

8.13 Invocación de guix repl

La orden guix repl lanza una sesión interactiva Guile (REPL) para la programación interactiva (see Using Guile Interactively in GNU Guile Reference Manual), o para la ejecución de guiones de Guile. Comparado a simplemente lanzar la orden guile, guix repl garantiza que todos los módulos Guix y todas sus dependencias están disponibles en la ruta de búsqueda.

La sintaxis general es:

guix repl opciones [archivo parámetros]

Cuando se proporciona archivo, archivo se ejecuta como un guión de Guile:

guix repl mi-guion.scm

Para proporcionar parámetros al guión, use -- para evitar que se interpreten como parámetros específicos de guix repl:

guix repl -- mi-guion.scm --input=foo.txt

Pare hacer que un guión sea ejecutable directamente desde el shell, mediante el uso del ejecutable de guix que se encuentre en la ruta de búsqueda de la usuaria, escriba las siguientes dos líneas al inicio del archivo:

#!/usr/bin/env -S guix repl --
!#

Si no se proporciona un nombre de archivo, se inicia una sesión interactiva (REPL) de Guile:

$ guix repl
scheme@(guile-user)> ,use (gnu packages base)
scheme@(guile-user)> coreutils
$1 = #<package coreutils@8.29 gnu/packages/base.scm:327 3e28300>

Además, guix repl implementa un protocolo del REPL simple legible por máquinas para su uso por (guix inferior), una facilidad para interactuar con inferiores, procesos separados que ejecutan una revisión de Guix potencialmente distinta.

Las opciones disponibles son las siguientes:

--type=tipo
-t tipo

Inicia un REPL del TIPO dado, que puede ser uno de los siguientes:

guile

Es el predeterminado, y lanza una sesión interactiva Guile estándar con todas las características.

machine

Lanza un REPL que usa el protocolo legible por máquinas. Este es el protocolo con el que el módulo (guix inferior) se comunica.

--listen=destino

Por defecto, guix repl lee de la entrada estándar y escribe en la salida estándar. Cuando se pasa esta opción, en vez de eso escuchará las conexiones en destino. Estos son ejemplos de opciones válidas:

--listen=tcp:37146

Acepta conexiones locales por el puerto 37146.

--listen=unix:/tmp/socket

Acepta conexiones a través del socket de dominio Unix /tmp/socket.

--load-path=directorio
-L directorio

Añade directorio al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles al guión o a la sesión interactiva.

-q

Inhibe la carga del archivo ~/.guile. De manera predeterminada, dicho archivo de configuración se carga al lanzar una sesión interactiva de guile.


Next: , Previous: , Up: Top   [Contents][Index]

9 Utilidades

Esta sección describe las utilidades de línea de órdenes de Guix. Algunas de ellas están orientadas principalmente para desarrolladoras y usuarias que escriban definiciones de paquetes nuevas, mientras que otras son útiles de manera más general. Complementan la interfaz programática Scheme de Guix de modo conveniente.


Next: , Up: Utilidades   [Contents][Index]

9.1 Invocación de guix build

La orden guix build construye paquetes o derivaciones y sus dependencias, e imprime las rutas del almacén resultantes. Fíjese que no modifica el perfil de la usuaria—este es el trabajo de la orden guix package (see Invocación de guix package). Por tanto, es útil principalmente para las desarrolladoras de la distribución.

La sintaxis general es:

guix build opciones paquete-o-derivación

Como ejemplo, la siguiente orden construye las últimas versiones de Emacs y Guile, muestra sus log de construcción, y finalmente muestra los directorios resultantes:

guix build emacs guile

De forma similar, la siguiente orden construye todos los paquetes disponibles:

guix build --quiet --keep-going \
  $(guix package -A | awk '{ print $1 "@" $2 }')

paquete-o-derivación puede ser tanto el nombre de un paquete que se encuentra en la distribución de software como coreutils o coreutils@8.20, o una derivación como /gnu/store/…-coreutils-8.19.drv. En el primer caso, el paquete de nombre (y opcionalmente versión) correspondiente se busca entre los módulos de la distribución GNU (see Módulos de paquetes).

De manera alternativa, la opción --expression puede ser usada para especificar una expresión Scheme que evalúa a un paquete; esto es útil para diferenciar entre varios paquetes con el mismo nombre o si se necesitan variaciones del paquete.

Puede haber cero o más opciones. Las opciones disponibles se describen en la subsección siguiente.


Next: , Up: Invocación de guix build   [Contents][Index]

9.1.1 Opciones comunes de construcción

Un número de opciones que controlan el proceso de construcción son comunes a guix build y otras órdenes que pueden lanzar construcciones, como guix package o guix archive. Son las siguientes:

--load-path=directorio
-L directorio

Añade directorio al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles a las herramientas de línea de órdenes.

--keep-failed
-K

Mantiene los árboles de construcción de las construcciones fallidas. Por tanto, si una construcción falla, su árbol de construcción se mantiene bajo /tmp, en un directorio cuyo nombre se muestra al final del log de construcción. Esto es útil cuando se depuran problemas en la construcción. See Depuración de fallos de construcción, para trucos y consejos sobre cómo depurar problemas en la construcción.

Esta opción implica --no-offload, y no tiene efecto cuando se conecta a un daemon remoto con una URI guix:// (see la variable GUIX_DAEMON_SOCKET).

--keep-going
-k

Seguir adelante cuando alguna de las derivaciones de un fallo durante la construcción; devuelve una única vez todas las construcciones que se han completado o bien han fallado.

El comportamiento predeterminado es parar tan pronto una de las derivaciones especificadas falle.

--dry-run
-n

No construye las derivaciones.

--fallback

Cuando la sustitución de un binario preconstruido falle, intenta la construcción local de paquetes (see Fallos en las sustituciones).

--substitute-urls=urls

Considera urls la lista separada por espacios de URLs de fuentes de sustituciones, anulando la lista predeterminada de URLs de guix-daemon (see guix-daemon URLs).

Significa que las sustituciones puede ser descargadas de urls, mientras que estén firmadas por una clave autorizada por la administradora del sistema (see Sustituciones).

Cuando urls es la cadena vacía, las sustituciones están efectivamente desactivadas.

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

--no-grafts

No “injerta” paquetes. En la práctica esto significa que las actualizaciones de paquetes disponibles como injertos no se aplican. See Actualizaciones de seguridad, para más información sobre los injertos.

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

Esto es útil para la detección de procesos de construcción no-deterministas. Los procesos de construcción no-deterministas son un problema puesto que prácticamente imposibilitan a las usuarias la verificación de la autenticidad de binarios proporcionados por terceras partes. See Invocación de guix challenge, para más sobre esto.

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.

--no-offload

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

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

Por defecto, se respeta la configuración del daemon (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.

Por defecto, se respeta la configuración del daemon (see --timeout).

-v nivel
--verbosity=nivel

Use the given verbosity level, an integer. Choosing 0 means that no output is produced, 1 is for quiet output; 2 is similar to 1 but it additionally displays download URLs; 3 shows all the build log output on standard error.

--cores=n
-c n

Permite usar n núcleos de la CPU para la construcción. El valor especial 0 significa usar tantos como núcleos haya en la CPU.

--max-jobs=n
-M n

Permite como máximo n trabajos de construcción en paralelo. See --max-jobs, para detalles acerca de esta opción y la opción equivalente de guix-daemon.

--debug=nivel

Usa el nivel de detalle proporcionado en los mensajes procedentes del daemon de construcción. nivel debe ser un entero entre 0 y 5; valores mayores indican una salida más detallada. Establecer un nivel de 4 o superior puede ser útil en la depuración de problemas de configuración con el daemon de construcción.

Tras las cortinas, guix build es esencialmente una interfaz al procedimiento package-derivation del módulo (guix packages), y al procedimiento build-derivations del módulo (guix derivations).

Además de las opciones proporcionadas explícitamente en la línea de órdenes, guix build y otras órdenes guix que permiten la construcción respetan el contenido de la variable de entorno GUIX_BUILD_OPTIONS.

Variable de entorno: GUIX_BUILD_OPTIONS

Las usuarias pueden definir esta variable para que contenga una lista de opciones de línea de órdenes que se usarán automáticamente por guix build y otras órdenes guix que puedan realizar construcciones, como en el ejemplo siguiente:

$ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"

Estas opciones se analizan independientemente, y el resultado se añade a continuación de las opciones de línea de órdenes.


Next: , Previous: , Up: Invocación de guix build   [Contents][Index]

9.1.2 Opciones de transformación de paquetes

Otro conjunto de opciones de línea de órdenes permitidas por guix build y también guix package son las opciones de transformación de paquetes. Son opciones que hacen posible la definición de variaciones de paquetes—por ejemplo, paquetes construidos con un código fuente diferente. Es una forma conveniente de crear paquetes personalizados al vuelo sin tener que escribir las definiciones de las variaciones del paquete (see Definición de paquetes).

Las opciones de transformación del paquete se preservan con las actualizaciones: guix upgrade intenta aplicar las opciones de transformación usadas inicialmente al crear el perfil para actualizar los paquetes.

Las opciones disponibles se enumeran a continuación. La mayor parte de las ordenes los aceptan, así como la opción --help-transform que enumera todas las opciones disponibles y una sinópsis (estas opciones no se muestran en la salida de --help por brevedad).

--tune[=cpu]

Use versions of the packages marked as “tunable” optimized for cpu. When cpu is native, or when it is omitted, tune for the CPU on which the guix command is running.

Valid cpu names are those recognized by the underlying compiler, by default the GNU Compiler Collection. On x86_64 processors, this includes CPU names such as nehalem, haswell, and skylake (see -march in Using the GNU Compiler Collection (GCC)).

As new generations of CPUs come out, they augment the standard instruction set architecture (ISA) with additional instructions, in particular instructions for single-instruction/multiple-data (SIMD) parallel processing. For example, while Core2 and Skylake CPUs both implement the x86_64 ISA, only the latter supports AVX2 SIMD instructions.

The primary gain one can expect from --tune is for programs that can make use of those SIMD capabilities and that do not already have a mechanism to select the right optimized code at run time. Packages that have the tunable? property set are considered tunable packages by the --tune option; a package definition with the property set looks like this:

(package
  (name "hello-simd")
  ;; ...

  ;; This package may benefit from SIMD extensions so
  ;; mark it as "tunable".
  (properties '((tunable? . #t))))

Other packages are not considered tunable. This allows Guix to use generic binaries in the cases where tuning for a specific CPU is unlikely to provide any gain.

Tuned packages are built with -march=CPU; under the hood, the -march option is passed to the actual wrapper by a compiler wrapper. Since the build machine may not be able to run code for the target CPU micro-architecture, the test suite is not run when building a tuned package.

To reduce rebuilds to the minimum, tuned packages are grafted onto packages that depend on them (see grafts). Thus, using --no-grafts cancels the effect of --tune.

We call this technique package multi-versioning: several variants of tunable packages may be built, one for each CPU variant. It is the coarse-grain counterpart of function multi-versioning as implemented by the GNU tool chain (see Function Multiversioning in Using the GNU Compiler Collection (GCC)).

--with-source=fuente
--with-source=paquete=fuente
--with-source=paquete@versión=fuente

Usa fuente como la fuente de paquete, y versión como su número de versión. fuente debe ser un nombre de archivo o una URL, como en guix download (see Invocación de guix download).

Cuando se omite paquete, se toma el nombre de paquete especificado en la línea de ordenes que coincide con el nombre base de fuente—por ejemplo, si fuente fuese /src/guile-2.0.10.tar.gz, el paquete correspondiente sería guile.

Del mismo modo, si se omite versión, la cadena de versión se deduce de đuente; en el ejemplo previo sería 2.0.10.

Esta opción permite a las usuarias probar versiones del paquete distintas a las proporcionadas en la distribución. El ejemplo siguiente descarga ed-1.7.tar.gz de un espejo GNU y lo usa como la fuente para el paquete ed:

guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz

Como desarrolladora, --with-source facilita la prueba de versiones candidatas para la publicación:

guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz

… o la construcción desde una revisión en un entorno limpio:

$ git clone git://git.sv.gnu.org/guix.git
$ guix build guix --with-source=guix@1.0=./guix
--with-input=paquete=reemplazo

Substituye dependencias de paquete por dependencias de reemplazo. paquete debe ser un nombre de paquete, y reemplazo debe ser una especificación de paquete como guile o guile@1.8.

Por ejemplo, la orden siguiente construye Guix, pero substituye su dependencia de la versión estable actual de Guile con una dependencia en la versión antigua de Guile, guile@2.0:

guix build --with-input=guile=guile@2.0 guix

Esta sustitución se realiza de forma recursiva y en profundidad. Por lo que en este ejemplo, tanto guix como su dependencia guile-json (que también depende de guile) se reconstruyen contra guile@2.0.

Se implementa usando el procedimiento Scheme package-input-rewriting (see package-input-rewriting).

--with-graft=paquete=reemplazo

Es similar a --with-input pero con una diferencia importante: en vez de reconstruir la cadena de dependencias completa, reemplazo se construye y se injerta en los binarios que inicialmente hacían referencia a paquete. See Actualizaciones de seguridad, para más información sobre injertos.

Por ejemplo, la orden siguiente injerta la versión 3.5.4 de GnuTLS en Wget y todas sus dependencias, substituyendo las referencias a la versión de GnuTLS que tienen actualmente:

guix build --with-graft=gnutls=gnutls@3.5.4 wget

Esta opción tiene la ventaja de ser mucho más rápida que la reconstrucción de todo. Pero hay una trampa: funciona si y solo si paquete y reemplazo son estrictamente compatibles—por ejemplo, si proporcionan una biblioteca, la interfaz binaria de aplicación (ABI) de dichas bibliotecas debe ser compatible. Si reemplazo es incompatible de alguna manera con paquete, el paquete resultante puede no ser usable. ¡Úsela con precaución!

--with-debug-info=paquete

Construye paquete de modo que preserve su información de depuración y lo injerta en los paquetes que dependan de él. Es útil si paquete no proporciona ya información de depuración como una salida debug (see Instalación de archivos de depuración).

Por ejemplo, supongamos que está experimentando un fallo en Inkscape y querría ver qué pasa en GLib, una biblioteca con mucha profundidad en el grafo de dependencias de Inkscape. GLib no tiene una salida debug, de modo que su depuración es difícil. Afortunadamente puede reconstruir GLib con información de depuración e incorporarla a Inkscape:

guix install inkscape --with-debug-info=glib

Únicamente GLib necesita una reconstrucción por lo que esto tarda un tiempo razonable. See Instalación de archivos de depuración para obtener más información.

Nota: Esta opción funciona en su implementación interna proporcionando ‘#:strip-binaries? #f’ al sistema de construcción del paquete en cuestión (see Sistemas de construcción). La mayor parte de sistemas de construcción implementan dicha opción, pero algunos no lo hacen. En este caso caso se emite un error.

De igual modo, si se construye un paquete C/C++ sin la opción -g (lo que no es habitual que ocurra), la información de depuración seguirá sin estar disponible incluso cuando #:strip-binaries? sea falso.

--with-c-toolchain=paquete=cadena

Esta opción cambia la compilación de paquete y todo lo que dependa de él de modo que se constuya con cadena en vez de la cadena de herramientas de construcción para C/C++ de GNU predeterminada.

Considere este ejemplo:

guix build octave-cli \
  --with-c-toolchain=fftw=gcc-toolchain@10 \
  --with-c-toolchain=fftwf=gcc-toolchain@10

La orden anterior construye una variante de los paquetes fftw y fftwf usando la versión 10 de gcc-toolchain en vez de la cadena de herramientas de construcción predeterminada, y construye una variante de la interfaz de línea de órdenes GNU Octave que hace uso de ellos. El propio paquete de GNU Octave también se construye con gcc-toolchain@10.

Este otro ejemplo construye la biblioteca Hardware Locality (hwloc) y los paquetes que dependan de ella hasta intel-mpi-benchmarks con el compilador de C Clang:

guix build --with-c-toolchain=hwloc=clang-toolchain \
           intel-mpi-benchmarks

Nota: There can be application binary interface (ABI) incompatibilities among tool chains. This is particularly true of the C++ standard library and run-time support libraries such as that of OpenMP. By rebuilding all dependents with the same tool chain, --with-c-toolchain minimizes the risks of incompatibility but cannot entirely eliminate them. Choose package wisely.

--with-git-url=paquete=url

Construye paquete desde la última revisión de la rama master del repositorio Git en url. Los submódulos del repositorio Git se obtienen de forma recursiva.

Por ejemplo, la siguiente orden construye la biblioteca NumPy de Python contra la última revisión de la rama master de Python en sí:

guix build python-numpy \
  --with-git-url=python=https://github.com/python/cpython

Esta opción también puede combinarse con --with-branch o --with-commit (véase más adelante).

Obviamente, ya que se usa la última revisión de la rama proporcionada, el resultado de dicha orden varia con el tiempo. No obstante es una forma conveniente de reconstruir una pila completa de software contra las últimas revisiones de uno o varios paquetes. Esto es particularmente útil en el contexto de integración continua (CI).

Los directorios de trabajo se conservan en caché en ~/.cache/guix/checkouts para agilizar accesos consecutivos al mismo repositorio. Puede desear limpiarla de vez en cuando para ahorrar espacio en el disco.

--with-branch=paquete=rama

Construye paquete desde la última revisión de rama. Si el campo source de paquete es un origen con el método git-fetch (see Referencia de origin) o un objeto git-checkout, la URL del repositorio se toma de dicho campo source. En otro caso, se debe especificar la URL del repositorio Git mediante el uso de --with-git-url.

Por ejemplo, la siguiente orden construye guile-sqlite3 desde la última revisión de su rama master y, una vez hecho, construye guix (que depende de él) y cuirass (que depende de guix) en base a esta construcción específica de guile-sqlite3:

guix build --with-branch=guile-sqlite3=master cuirass
--with-commit=paquete=revisión

This is similar to --with-branch, except that it builds from commit rather than the tip of a branch. commit must be a valid Git commit SHA1 identifier, a tag, or a git describe style identifier such as 1.0-3-gabc123.

--with-patch=package=file

Add file to the list of patches applied to package, where package is a spec such as python@3.8 or glibc. file must contain a patch; it is applied with the flags specified in the origin of package (see Referencia de origin), which by default includes -p1 (see patch Directories in Comparing and Merging Files).

As an example, the command below rebuilds Coreutils with the GNU C Library (glibc) patched with the given patch:

guix build coreutils --with-patch=glibc=./glibc-frob.patch

In this example, glibc itself as well as everything that leads to Coreutils in the dependency graph is rebuilt.

--with-latest=package

So you like living on the bleeding edge? This option is for you! It replaces occurrences of package in the dependency graph with its latest upstream version, as reported by guix refresh (see Invocación de guix refresh).

It does so by determining the latest upstream release of package (if possible), downloading it, and authenticating it if it comes with an OpenPGP signature.

As an example, the command below builds Guix against the latest version of Guile-JSON:

guix build guix --with-latest=guile-json

There are limitations. First, in cases where the tool cannot or does not know how to authenticate source code, you are at risk of running malicious code; a warning is emitted in this case. Second, this option simply changes the source used in the existing package definitions, which is not always sufficient: there might be additional dependencies that need to be added, patches to apply, and more generally the quality assurance work that Guix developers normally do will be missing.

You’ve been warned! In all the other cases, it’s a snappy way to stay on top. We encourage you to submit patches updating the actual package definitions once you have successfully tested an upgrade (see Contribuir).

--without-tests=paquete

Construye paquete sin ejecutar su batería de pruebas. Puede ser útil en situaciones en las que quiera omitir una larga batería de pruebas de un paquete intermedio, o si la batería de pruebas no falla de manera determinista. Debe usarse con cuidado, puesto que la ejecución de la batería de pruebas es una buena forma de asegurarse de que el paquete funciona como se espera.

La desactivación de las pruebas conduce a diferentes elementos en el almacén. Por tanto, cuando use esta opción, cualquier objeto que dependa de paquete debe ser reconstruido, como en este ejemplo:

guix install --without-tests=python python-notebook

La orden anterior instala python-notebook sobre un paquete python construido sin ejecutar su batería de pruebas. Para hacerlo, también reconstruye todos los paquetes que dependen de python, incluyendo el propio pyhton-notebook.

De manera interna, --without-tests depende del cambio de la opción #:tests? de la fase check del paquete (see Sistemas de construcción). Tenga en cuenta que algunos paquetes usan una fase check personalizada que no respeta el valor de configuración #:tests? #f. Por tanto, --without-tests no tiene ningún efecto en dichos paquetes.

¿Se pregunta cómo conseguir el mismo efecto usando código Scheme, por ejemplo en su manifiesto, o cómo escribir su propia transformación de paquetes? See Definición de variantes de paquetes para obtener una descripción de la interfaz programática disponible.


Next: , Previous: , Up: Invocación de guix build   [Contents][Index]

9.1.3 Opciones de construcción adicionales

Las opciones de línea de ordenes presentadas a continuación son específicas de guix build.

--quiet
-q

Construye silenciosamente, sin mostrar el registro de construcción; es equivalente a --verbosity=0. Al finalizar, el registro de construcción se mantiene en /var (o similar) y puede recuperarse siempre mediante el uso de la opción --log-file.

--file=archivo
-f archivo

Construye el paquete, derivación u otro objeto tipo-archivo al que evalúa el código en archivo (see objetos “tipo-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+))

El archivo también puede contener una representación en JSON de una o más definiciones de paquete. Ejecutar guix build -f en hello.json con el siguiente contenido resultaría en la construcción de los paquetes myhello y greeter:

[
  {
    "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"]
  }
]
--manifest=manifiesto
-m manifiesto

Construye todos los paquetes listados en el manifiesto proporcionado (see --manifest).

--expression=expr
-e expr

Construye el paquete o derivación a la que evalúa expr.

Por ejemplo, expr puede ser (@ (gnu packages guile) guile-1.8), que designa sin ambigüedad a esta variante específica de la versión 1.8 de Guile.

De manera alternativa, expr puede ser una expresión-G, en cuyo caso se usa como un programa de construcción pasado a gexp->derivation (see Expresiones-G).

Por último, expr puede hacer referencia a un procedimiento mónadico sin parámetros (see La mónada del almacén). El procedimiento debe devolver una derivación como un valor monádico, el cual después se pasa a través de run-with-store.

--source
-S

Construye las derivaciones de las fuentes de los paquetes, en vez de los paquetes mismos.

Por ejemplo, guix build -S gcc devuelve algo como /gnu/store/…-gcc-4.7.2.tar.bz2, el cual es el archivador tar de fuentes de GCC.

El archivador tar devuelto es el resultado de aplicar cualquier parche y fragmento de código en el origen (campo origin) del paquete (see Definición de paquetes).

As with other derivations, the result of building a source derivation can be verified using the --check option (see build-check). This is useful to validate that a (potentially already built or substituted, thus cached) package source matches against its declared hash.

Tenga en cuenta que guix build -S compila las fuentes únicamente de los paquetes especificados. Esto no incluye las dependencias enlazadas estáticamente y por sí mismas son insuficientes para reproducir los paquetes.

--sources

Obtiene y devuelve las fuentes de paquete-o-derivación y todas sus dependencias, de manera recursiva. Esto es útil para obtener una copia local de todo el código fuente necesario para construir los paquetes, le permite construirlos llegado el momento sin acceso a la red. Es una extensión de la opción --source y puede aceptar uno de los siguientes valores opcionales como parámetro:

package

Este valor hace que la opción --sources se comporte de la misma manera que la opción --source.

all

Construye las derivaciones de las fuentes de todos los paquetes, incluyendo cualquier fuente que pueda enumerarse como entrada (campo inputs). Este es el valor predeterminado.

$ guix build --sources tzdata
The following derivations will be built:
   /gnu/store/…-tzdata2015b.tar.gz.drv
   /gnu/store/…-tzcode2015b.tar.gz.drv
transitive

Construye las derivaciones de fuentes de todos los paquetes, así como todas las entradas transitivas de los paquetes. Esto puede usarse, por ejemplo, para obtener las fuentes de paquetes para una construcción posterior sin conexión a la red.

$ guix build --sources=transitive tzdata
The following derivations will be built:
   /gnu/store/…-tzcode2015b.tar.gz.drv
   /gnu/store/…-findutils-4.4.2.tar.xz.drv
   /gnu/store/…-grep-2.21.tar.xz.drv
   /gnu/store/…-coreutils-8.23.tar.xz.drv
   /gnu/store/…-make-4.1.tar.xz.drv
   /gnu/store/…-bash-4.3.tar.xz.drv
…
--system=sistema
-s sistema

Intenta la construcción para sistema—por ejemplo, i686-linux—en vez del tipo de sistema de la máquina de construcción. La orden guix build le permite repetir esta opción varias veces, en cuyo caso construye para todos los sistemas especificados; otras ordenes ignoran opciones -s extrañas.

Nota: La opción --system es para compilación nativa y no debe confundirse con la compilación cruzada. Véase --target más adelante para información sobre compilación cruzada.

Un ejemplo de uso de esta opción es en sistemas basados en Linux, que pueden emular diferentes personalidades. Por ejemplo, proporcionar la opción --system=i686-linux en un sistema x86_64-linux, o la opción --system=armhf-linux en un sistema aarch64-linux, le permite construir paquetes en un entorno de 32-bits completo.

Nota: La construcción para un sistema armhf-linux está disponible de manera incondicional en máquinas aarch64-linux, aunque determinadas familias de procesadores aarch64 no lo permitan, notablemente el ThunderX.

De manera similar, cuando la emulación transparente con QEMU y binfmt_misc está activada (see qemu-binfmt-service-type), puede construir para cualquier sistema para el que un manejador QEMU de binfmt_misc esté instalado.

Las construcciones para un sistema distinto al de la máquina que usa se pueden delegar también a una máquina remota de la arquitectura correcta. See Configuración de delegación del daemon, para más información sobre delegació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).

--check

Reconstruye paquete-o-derivación, que ya está disponible en el almacén, y emite un error si los resultados de la construcción no son idénticos bit-a-bit.

Este mecanismo le permite comprobar si sustituciones previamente instaladas son genuinas (see Sustituciones), o si el resultado de la construcción de un paquete es determinista. See Invocación de guix challenge, para más información de referencia y herramientas.

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.

--repair

Intenta reparar los elementos del almacén especificados, si están corruptos, volviendo a descargarlos o mediante su reconstrucción.

Esta operación no es atómica y por lo tanto está restringida a root.

--derivations
-d

Devuelve las rutas de derivación, no las rutas de salida, de los paquetes proporcionados.

--root=archivo
-r archivo

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

Consecuentemente, los resultados de esta invocación de guix build se protegen de la recolección de basura hasta que archivo se elimine. Cuando se omite esa opción, los resultados son candidatos a la recolección de basura en cuanto la construcción se haya completado. See Invocación de guix gc, para más sobre las raíces del recolector de basura.

--log-file

Devuelve los nombres de archivos o URL de los log de construcción para el paquete-o-derivación proporcionado, o emite un error si no se encuentran los log de construcción.

Esto funciona independientemente de cómo se especificasen los paquetes o derivaciones. Por ejemplo, las siguientes invocaciones son equivalentes:

guix build --log-file $(guix build -d guile)
guix build --log-file $(guix build guile)
guix build --log-file guile
guix build --log-file -e '(@ (gnu packages guile) guile-2.0)'

Si no está disponible un registro local, y a menos que se proporcione --no-substitutes, la orden busca el registro correspondiente en uno de los servidores de sustituciones (como se especificaron con --substitute-urls).

Por lo que dado el caso, imaginese que desea ver el log de construcción de GDB en MIPS, pero realmente está en una máquina x86_64:

$ guix build --log-file gdb -s aarch64-linux
https://ci.guix.gnu.org/log/…-gdb-7.10

¡Puede acceder libremente a una biblioteca inmensa de log de construcción!


Previous: , Up: Invocación de guix build   [Contents][Index]

9.1.4 Depuración de fallos de construcción

Cuando esté definiendo un paquete nuevo (see Definición de paquetes), probablemente se encuentre que dedicando algún tiempo a depurar y afinar la construcción hasta obtener un resultado satisfactorio. Para hacerlo, tiene que lanzar manualmente las órdenes de construcción en un entorno tan similar como sea posible al que el daemon de construcción usa.

To that end, the first thing to do is to use the --keep-failed or -K option of guix build, which will keep the failed build tree in /tmp or whatever directory you specified as TMPDIR (see --keep-failed).

De ahí en adelante, puede usar cd para ir al árbol de la construcción fallida y cargar el archivo environment-variables, que contiene todas las definiciones de variables de entorno que existían cuando la construcción falló. Digamos que está depurando un fallo en la construcción del paquete foo; una sesión típica sería así:

$ guix build foo -K
… build fails
$ cd /tmp/guix-build-foo.drv-0
$ source ./environment-variables
$ cd foo-1.2

Ahora puede invocar órdenes (casi) como si fuese el daemon y encontrar los errores en su proceso de construcción.

A veces ocurre que, por ejemplo, las pruebas de un paquete pasan cuando las ejecuta manualmente pero fallan cuando el daemon las ejecuta. Esto puede suceder debido a que el daemon construye dentro de contenedores donde, al contrario que en nuestro entorno previo, el acceso a la red no está disponible, /bin/sh no existe, etc. (see Configuración del entorno de construcción).

En esos casos, puede tener que inspeccionar el proceso de construcción desde un contenedor similar al creado por el daemon de construcción:

$ guix build -K foo
…
$ cd /tmp/guix-build-foo.drv-0
$ guix shell --no-grafts -C -D foo strace gdb
[env]# source ./environment-variables
[env]# cd foo-1.2

Here, guix shell -C creates a container and spawns a new shell in it (see Invoking guix shell). The strace gdb part adds the strace and gdb commands to the container, which you may find handy while debugging. The --no-grafts option makes sure we get the exact same environment, with ungrafted packages (see Actualizaciones de seguridad, for more info on grafts).

Para acercarnos más al contenedor usado por el daemon de construcción, podemos eliminar /bin/sh:

[env]# rm /bin/sh

(Don’t worry, this is harmless: this is all happening in the throw-away container created by guix shell.)

La orden strace probablemente no esté en la ruta de búsqueda, pero podemos ejecutar:

[env]# $GUIX_ENVIRONMENT/bin/strace -f -o log make check

De este modo, no solo habrá reproducido las variables de entorno que usa el daemon, también estará ejecutando el proceso de construcción en un contenedor similar al usado por el daemon.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.2 Invocación de guix edit

¡Tantos paquetes, tantos archivos de fuentes! La orden guix edit facilita la vida de las usuarias y empaquetadoras apuntando su editor al archivo de fuentes que contiene la definición de los paquetes especificados. Por ejemplo:

guix edit gcc@4.9 vim

ejecuta el programa especificado en la variable de entorno VISUAL o en EDITOR para ver la receta de GCC 4.9.3 y la de Vim.

Si está usando una copia de trabajo de Git de Guix (see Construcción desde Git), o ha creado sus propios paquetes en GUIX_PACKAGE_PATH (see Módulos de paquetes), será capaz de editar las recetas de los paquetes. En otros casos, podrá examinar las recetas en modo de lectura únicamente para paquetes actualmente en el almacén.

En vez de GUIX_PACKAGE_PATH, la opción de línea de ordenes --load-path=directorio (o en versión corta -L directorio) le permite añadir directorio al inicio de la ruta de búsqueda de módulos de paquete y hacer visibles sus propios paquetes.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.3 Invocación de guix download

Durante la escritura de una definición de paquete, las desarrolladoras típicamente tienen que descargar un archivador tar de fuentes, calcular su hash SHA256 y escribir ese hash en la definición del paquete (see Definición de paquetes). La herramienta guix download ayuda con esta tarea: descarga un archivo de la URI proporcionada, lo añade al almacén e imprime tanto su nombre de archivo en el almacén como su hash SHA256.

El hecho de que el archivo descargado se añada al almacén ahorra ancho de banda: cuando el desarrollador intenta construir el paquete recién definido con guix build, el archivador de fuentes no tiene que descargarse de nuevo porque ya está en el almacén. También es una forma conveniente de conservar archivos temporalmente, que pueden ser borrados en un momento dado (see Invocación de guix gc).

La orden guix download acepta las mismas URI que las usadas en las definiciones de paquetes. En particular, permite URI mirror://. Las URI https (HTTP sobre TLS) se aceptan cuando el enlace Guile con GnuTLS está disponible en el entorno de la usuaria; cuando no está disponible se emite un error. See how to install the GnuTLS bindings for Guile in GnuTLS-Guile, para más información.

guix download verifica los certificados del servidor HTTPS cargando las autoridades X.509 del directorio al que apunta la variable de entorno SSL_CERT_DIR (see Certificados X.509), a menos que se use --no-check-certificate.

Las siguientes opciones están disponibles:

--hash=algoritmo
-H algoritmo

Calcula el resultado del hash usando el algoritmo proporcionado. See Invocación de guix hash, para más información.

--format=fmt
-f fmt

Escribe el hash en el formato especificado por fmt. Para más información sobre los valores aceptados en fmt, see Invocación de guix hash.

--no-check-certificate

No valida los certificados X.509 de los servidores HTTPS.

Cuando se usa esta opción, no tiene absolutamente ninguna garantía de que está comunicando con el servidor responsable de la URL auténtico, lo que le hace vulnerables a ataques de interceptación (“man-in-the-middle”).

--output=archivo
-o archivo

Almacena el archivo descargado en archivo en vez de añadirlo al almacén.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.4 Invocación de guix hash

The guix hash command computes the hash of a file. It is primarily a convenience tool for anyone contributing to the distribution: it computes the cryptographic hash of one or more files, which can be used in the definition of a package (see Definición de paquetes).

La sintaxis general es:

guix hash option file ...

Cuando archivo es - (un guión), guix hash calcula el hash de los datos leídos por la entrada estándar. guix hash tiene las siguientes opciones:

--hash=algoritmo
-H algoritmo

Calcula un hash usando el algoritmo especificado, sha256 de manera predeterminada.

algorithm must be the name of a cryptographic hash algorithm supported by Libgcrypt via Guile-Gcrypt—e.g., sha512 or sha3-256 (see Hash Functions in Guile-Gcrypt Reference Manual).

--format=fmt
-f fmt

Escribe el hash en el formato especificado por fmt.

Los formatos disponibles son: base64, nix-base32, base32, base16 (se puede usar también hex y hexadecimal).

Si no se especifica la opción --format, guix hash mostrará el hash en nix-base32. Esta representación es la usada en las definiciones de paquetes.

--recursive
-r

The --recursive option is deprecated in favor of --serializer=nar (see below); -r remains accepted as a convenient shorthand.

--serializer=type
-S type

Compute the hash on file using type serialization.

type may be one of the following:

none

This is the default: it computes the hash of a file’s contents.

nar

Compute the hash of a “normalized archive” (or “nar”) containing file, including its children if it is a directory. Some of the metadata of file is part of the archive; for instance, when file is a regular file, the hash is different depending on whether file is executable or not. Metadata such as time stamps have no impact on the hash (see Invocación de guix archive, for more info on the nar format).

git

Compute the hash of the file or directory as a Git “tree”, following the same method as the Git version control system.

--exclude-vcs
-x

Cuando se combina con --recursive, excluye los directorios del sistema de control de versiones (.bzr, .git, .hg, etc.).

Como un ejemplo, así es como calcularía el hash de una copia de trabajo Git, lo cual es útil cuando se usa el método git-fetch (see Referencia de origin):

$ git clone http://example.org/foo.git
$ cd foo
$ guix hash -x --serializer=nar .

Next: , Previous: , Up: Utilidades   [Contents][Index]

9.5 Invocación de guix import

La orden guix import es útil para quienes desean añadir un paquete a la distribución con el menor trabajo posible—una demanda legítima. La orden conoce algunos repositorios de los que puede “importar” metadatos de paquetes. El resultado es una definición de paquete, o una plantilla de ella, en el formato que conocemos (see Definición de paquetes).

La sintaxis general es:

guix import importador opciones

importador especifica la fuente de la que se importan los metadatos del paquete, opciones especifica un identificador de paquete y otras opciones específicas del importador.

Algunos de los importadores dependen de poder ejecutar la orden gpgv. Para ello, GnuPG debe estar instalado y en $PATH; ejecute guix install gnupg si es necesario.

Actualmente los “importadores” disponibles son:

gnu

Importa los metadatos del paquete GNU seleccionado. Proporciona una plantilla para la última versión de dicho paquete GNU, incluyendo el hash de su archivador tar de fuentes, y su sinopsis y descripción canónica.

Información adicional como las dependencias del paquete y su licencia deben ser deducidas manualmente.

Por ejemplo, la siguiente orden devuelve una definición de paquete para GNU Hello.

guix import gnu hello

Las opciones específicas de línea de ordenes son:

--key-download=política

Como en guix refresh, especifica la política de tratamiento de las claves OpenPGP no encontradas cuando se verifica la firma del paquete. See --key-download.

pypi

Importa metadatos desde el índice de paquetes Python (PyPI). La información se toma de la descripción con formato JSON disponible en pypi.python.org y habitualmente incluye toda la información relevante, incluyendo las dependencias del paquete. Para una máxima eficiencia, se recomienda la instalación de la utilidad unzip, de manera que el importador pueda extraer los archivos wheel de Python y obtener datos de ellos.

The command below imports metadata for the latest version of the itsdangerous Python package:

guix import pypi itsdangerous

You can also ask for a specific version:

guix import pypi itsdangerous@1.1.0
--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

gem

Importa metadatos desde RubyGems. La información se extrae de la descripción en formato JSON disponible en rubygems.org e incluye la información más relevante, incluyendo las dependencias en tiempo de ejecución. Hay algunos puntos a tener en cuenta, no obstante. Los metadatos no distinguen entre sinopsis y descripción, por lo que se usa la misma cadena para ambos campos. Adicionalmente, los detalles de las dependencias no-Ruby necesarias para construir extensiones nativas no está disponible y se deja como ejercicio a la empaquetadora.

La siguiente orden importa los meta-datos para el paquete de Ruby rails:

guix import gem rails
--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

minetest

Import metadata from ContentDB. Information is taken from the JSON-formatted metadata provided through ContentDB’s API and includes most relevant information, including dependencies. There are some caveats, however. The license information is often incomplete. The commit hash is sometimes missing. The descriptions are in the Markdown format, but Guix uses Texinfo instead. Texture packs and subgames are unsupported.

The command below imports metadata for the Mesecons mod by Jeija:

guix import minetest Jeija/mesecons

The author name can also be left out:

guix import minetest mesecons
--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

cpan

Importa metadatos desde MetaCPAN. La información se extrae de la descripción en formato JSON disponible a través del API de MetaCPAN e incluye la información más relevante, como las dependencias de otros módulos. La información de la licencia debe ser comprobada atentamente. Si Perl está disponible en el almacén, se usará la utilidad corelist para borrar los módulos básicos de la lista de dependencias.

La siguiente orden importa los metadatos del módulo Perl Acme::Boolean:

guix import cpan Acme::Boolean
cran

Importa metadatos desde CRAN, el repositorio central para el entorno estadístico y gráfico GNU R.

La información se extrae del archivo DESCRIPTION del paquete.

La siguiente orden importa los metadatos del paquete de R Cairo:

guix import cran Cairo

You can also ask for a specific version:

guix import cran rasterVis@0.50.3

Cuando se añade --recursive, el importador recorrerá el grafo de dependencias del paquete original proporcionado recursivamente y generará expresiones de paquetes para todos aquellos que no estén todavía en Guix.

When --style=specification is added, the importer will generate package definitions whose inputs are package specifications instead of references to package variables. This is useful when generated package definitions are to be appended to existing user modules, as the list of used package modules need not be changed. The default is --style=variable.

Cuando se usa --archive=bioconductor, los metadatos se importan de Bioconductor, un repositorio de paquetes R para el análisis y comprensión de datos genéticos de alto caudal en bioinformática.

La información se extrae del archivo DESCRIPTION contenido en el archivo del paquete.

La siguiente orden importa los metadatos del paquete de R GenomicRanges:

guix import cran --archive=bioconductor GenomicRanges

Por último, también puede importar paquetes de R que no se hayan publicado todavía en CRAN o en Bioconductor siempre que estén en un repositorio git. Use --archive=git seguido de la URL del repositorio git:

guix import cran --archive=git https://github.com/immunogenomics/harmony
texlive

Import TeX package information from the TeX Live package database for TeX packages that are part of the TeX Live distribution.

Information about the package is obtained from the TeX Live package database, a plain text file that is included in the texlive-bin package. The source code is downloaded from possibly multiple locations in the SVN repository of the Tex Live project.

La siguiente orden importa los metadatos del paquete de TeX fontspec:

guix import texlive fontspec
json

Importa metadatos de paquetes desde un archivo JSON local. Considere el siguiente ejemplo de definición de paquete en formato JSON:

{
  "name": "hello",
  "version": "2.10",
  "source": "mirror://gnu/hello/hello-2.10.tar.gz",
  "build-system": "gnu",
  "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"]
}

Los nombres de los campos son los mismos que para el registro <package> (See Definición de paquetes). Las referencias a otros paquetes se proporcionan como listas JSON de cadenas de especificación de paquete entrecomilladas como guile o guile@2.0.

El importador también permite una definición de fuentes más explícita usando los campos comunes de los registros <origin>:

{
  …
  "source": {
    "method": "url-fetch",
    "uri": "mirror://gnu/hello/hello-2.10.tar.gz",
    "sha256": {
      "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
    }
  }
  …
}

La siguiente orden importa los metadatos desde el archivo JSON hello.json y devuelve una expresión de “package”:

guix import json hello.json
hackage

Importa metadatos desde el archivo central de paquetes de la comunidad Haskell Hackage. La información se obtiene de archivos Cabal e incluye toda la información relevante, incluyendo las dependencias del paquete.

Las opciones específicas de línea de ordenes son:

--stdin
-s

Lee un archivo Cabal por la entrada estándar.

--no-test-dependencies
-t

No incluye las dependencias necesarias únicamente para las baterías de pruebas.

--cabal-environment=alist
-e alist

alist es una lista asociativa Scheme que define el entorno en el que los condicionales Cabal se evalúan. Los valores aceptados son: os, arch, impl y una cadena que representa el nombre de la condición. El valor asociado a la condición tiene que ser o bien el símbolo true o bien false. Los valores predeterminados asociados a las claves os, arch y impl son ‘linux’, ‘x86_64’ y ‘ghc’, respectivamente.

--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

La siguiente orden importa los metadatos de la última versión del paquete Haskell HTTP sin incluir las dependencias de las pruebas y especificando la opción ‘network-uri’ con valor false:

guix import hackage -t -e "'((\"network-uri\" . false))" HTTP

Se puede especificar opcionalmente una versión específica del paquete añadiendo al nombre del paquete una arroba y el número de versión como en el siguiente ejemplo:

guix import hackage mtl@2.1.3.1
stackage

El importador stackage es un recubrimiento sobre el de hackage. Toma un nombre de paquete, busca la versión de paquete incluida en una publicación de la versión de mantenimiento extendido (LTS) Stackage y usa el importador hackage para obtener sus metadatos. Fíjese que es su decisión seleccionar una publicación LTS compatible con el compilador GHC usado en Guix.

Las opciones específicas de línea de ordenes son:

--no-test-dependencies
-t

No incluye las dependencias necesarias únicamente para las baterías de pruebas.

--lts-version=versión
-l versión

versión es la versión LTS de publicación deseada. Si se omite se usa la última publicación.

--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

La siguiente orden importa los metadatos del paquete Haskell HTTP incluido en la versión de publicación LTS de Stackage 7.18:

guix import stackage --lts-version=7.18 HTTP
elpa

Importa metadatos desde el repositorio de archivos de paquetes Emacs Lisp (ELPA) (see Packages in The GNU Emacs Manual).

Las opciones específicas de línea de ordenes son:

--archive=repo
-a repo

repo identifica el repositorio de archivos del que obtener la información. Actualmente los repositorios disponibles y sus identificadores son:

  • - GNU, seleccionado con el identificador gnu. Utilizado de manera predeterminada.

    Los paquetes de elpa.gnu.org están firmados con una de las claves que contiene el anillo de claves GnuPG en share/emacs/25.1/etc/package-keyring.gpg (o similar) en el paquete emacs (see ELPA package signatures in The GNU Emacs Manual).

  • - NonGNU, selected by the nongnu identifier.
  • - MELPA-Stable, seleccionado con el identificador melpa-stable.
  • - MELPA, seleccionado con el identificador melpa.
--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

crate

Importa metadatos desde el repositorio de paquetes Rust crates.io, como en este ejemplo:

guix import crate blake2-rfc

El importador de crate también le permite especificar una cadena de versión:

guix import crate constant-time-eq@0.1.0

La opciones adicionales incluyen:

--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

opam

Importa metadatos desde el repositorio de paquetes OPAM usado por la comunidad OCaml.

La opciones adicionales incluyen:

--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

--repo

By default, packages are searched in the official OPAM repository. This option, which can be used more than once, lets you add other repositories which will be searched for packages. It accepts as valid arguments:

  • the name of a known repository - can be one of opam, coq (equivalent to coq-released), coq-core-dev, coq-extra-dev or grew.
  • the URL of a repository as expected by the opam repository add command (for instance, the URL equivalent of the above opam name would be https://opam.ocaml.org).
  • the path to a local copy of a repository (a directory containing a packages/ sub-directory).

Repositories are assumed to be passed to this option by order of preference. The additional repositories will not replace the default opam repository, which is always kept as a fallback.

Also, please note that versions are not compared across repositories. The first repository (from left to right) that has at least one version of a given package will prevail over any others, and the version imported will be the latest one found in this repository only.

go

Import metadata for a Go module using proxy.golang.org.

guix import go gopkg.in/yaml.v2

It is possible to use a package specification with a @VERSION suffix to import a specific version.

La opciones adicionales incluyen:

--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

--pin-versions

When using this option, the importer preserves the exact versions of the Go modules dependencies instead of using their latest available versions. This can be useful when attempting to import packages that recursively depend on former versions of themselves to build. When using this mode, the symbol of the package is made by appending the version to its name, so that multiple versions of the same package can coexist.

egg

Import metadata for CHICKEN eggs. The information is taken from PACKAGE.egg files found in the eggs-5-all Git repository. However, it does not provide all the information that we need, there is no “description” field, and the licenses used are not always precise (BSD is often used instead of BSD-N).

guix import egg sourcehut

You can also ask for a specific version:

guix import egg arrays@1.0

La opciones adicionales incluyen:

--recursive
-r

Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

La estructura del código de guix import es modular. Sería útil tener más importadores para otros formatos de paquetes, y su ayuda es bienvenida aquí (see Contribuir).


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.6 Invocación de guix refresh

The primary audience of the guix refresh command is packagers. As a user, you may be interested in the --with-latest option, which can bring you package update superpowers built upon guix refresh (see --with-latest). By default, guix refresh reports any packages provided by the distribution that are outdated compared to the latest upstream version, like this:

$ guix refresh
gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0

De manera alternativa, se pueden especificar los paquetes a considerar, en cuyo caso se emite un aviso para paquetes que carezcan de actualizador:

$ guix refresh coreutils guile guile-ssh
gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh
gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13

guix refresh navega por los repositorios oficiales de cada paquete y determina el número de versión mayor entre las publicaciones encontradas. La orden sabe cómo actualizar tipos específicos de paquetes: paquetes GNU, paquetes ELPA, etc.—vea la documentación de --type más adelante. Hay muchos paquetes, no obstante, para los que carece de un método para determinar si está disponible una versión oficial posterior. No obstante, el mecanismo es extensible, ¡no tenga problema en contactar con nosotras para añadir un método nuevo!

--recursive

Considera los paquetes especificados, y todos los paquetes de los que dependen.

$ guix refresh --recursive coreutils
gnu/packages/acl.scm:40:13: acl would be upgraded from 2.2.53 to 2.3.1
gnu/packages/m4.scm:30:12: 1.4.18 is already the latest version of m4
gnu/packages/xml.scm:68:2: warning: no updater for expat
gnu/packages/multiprecision.scm:40:12: 6.1.2 is already the latest version of gmp
…

A veces el nombre oficial es diferente al nombre de paquete usado en Guix, y guix refresh necesita un poco de ayuda. La mayor parte de los actualizadores utilizan la propiedad upstream-name en las definiciones de paquetes, que puede usarse para obtener dicho efecto:

(define-public network-manager
  (package
    (name "network-manager")
    ;; …
    (properties '((upstream-name . "NetworkManager")))))

Cuando se proporciona --update, modifica los archivos de fuentes de la distribución para actualizar los números de versión y hash de los archivadores tar de fuentes en las recetas de los paquetes (see Definición de paquetes). Esto se consigue con la descarga del último archivador de fuentes del paquete y su firma OpenPGP asociada, seguida de la verificación del archivador descargado y su firma mediante el uso de gpg, y finalmente con el cálculo de su hash—tenga en cuenta que GnuPG debe estar instalado y en $PATH; ejecute guix install gnupg si es necesario.

Cuando la clave pública usada para firmar el archivador no se encuentra en el anillo de claves de la usuaria, se intenta automáticamente su obtención desde un servidor de claves públicas; cuando se encuentra, la clave se añade al anillo de claves de la usuaria; en otro caso, guix refresh informa de un error.

Se aceptan las siguientes opciones:

--expression=expr
-e expr

Considera el paquete al que evalúa expr

Es útil para hacer una referencia precisa de un paquete concreto, como en este ejemplo:

guix refresh -l -e '(@@ (gnu packages commencement) glibc-final)'

Esta orden enumera los paquetes que dependen de la libc “final” (esencialmente todos los paquetes).

--update
-u

Actualiza los archivos fuente de la distribución (recetas de paquetes) en su lugar. Esto se ejecuta habitualmente desde una copia de trabajo del árbol de fuentes de Guix (see Ejecución de Guix antes de estar instalado):

$ ./pre-inst-env guix refresh -s non-core -u

See Definición de paquetes, para más información sobre la definición de paquetes.

--select=[subconjunto]
-s subconjunto

Selecciona todos los paquetes en subconjunto, o bien core o bien non-core.

El subconjunto core hace referencia a todos los paquetes en el núcleo de la distribución—es decir, paquetes que se usan para construir “todo lo demás”. Esto incluye GCC, libc, Binutils, Bash, etc. Habitualmente, cambiar uno de esos paquetes en la distribución conlleva la reconstrucción de todos los demás. Por tanto, esas actualizaciones son una inconveniencia para las usuarias en términos de tiempo de construcción o ancho de banda usado por la actualización.

El subconjunto non-core hace referencia a los paquetes restantes. Es típicamente útil en casos donde una actualización de paquetes básicos no sería conveniente.

--manifest=archivo
-m archivo

Select all the packages from the manifest in file. This is useful to check if any packages of the user manifest can be updated.

--type=actualizador
-t actualizador

Selecciona únicamente paquetes manejados por actualizador (puede ser una lista separada por comas de actualizadores). Actualmente, actualizador puede ser:

gnu

el actualizador de paquetes GNU;

savannah

el actualizador para paquetes alojados en Savannah;

sourceforge

the updater for packages hosted at SourceForge;

gnome

el actualizador para paquetes GNOME;

kde

el actualizador para paquetes KDE;

xorg

el actualizador para paquetes X.org;

kernel.org

el actualizador para paquetes alojados en kernel.org;

egg

the updater for Egg packages;

elpa

el actualizador para paquetes ELPA;

cran

el actualizador para paquetes CRAN;

bioconductor

el actualizador para paquetes R Bioconductor;

cpan

el actualizador para paquetes CPAN;

pypi

el actualizador para paquetes PyPI.

gem

el actualizador para paquetes RubyGems.

github

el actualizador para paquetes GitHub.

hackage

el actualizador para paquetes Hackage.

stackage

el actualizador para paquetes Stackage.

crate

el actualizador para paquetes Crates.

launchpad

el actualizador para paquetes Launchpad.

generic-html

a generic updater that crawls the HTML page where the source tarball of the package is hosted, when applicable.

generic-git

a generic updater for packages hosted on Git repositories. It tries to be smart about parsing Git tag names, but if it is not able to parse the tag name and compare tags correctly, users can define the following properties for a package.

  • release-tag-prefix: a regular expression for matching a prefix of the tag name.
  • release-tag-suffix: a regular expression for matching a suffix of the tag name.
  • release-tag-version-delimiter: a string used as the delimiter in the tag name for separating the numbers of the version.
  • accept-pre-releases: by default, the updater will ignore pre-releases; to make it also look for pre-releases, set the this property to #t.
(package
  (name "foo")
  ;; ...
  (properties
    '((release-tag-prefix . "^release0-")
      (release-tag-suffix . "[a-z]?$")
      (release-tag-version-delimiter . ":"))))

Por ejemplo, la siguiente orden únicamente comprueba actualizaciones de paquetes Emacs alojados en elpa.gnu.org y actualizaciones de paquetes CRAN:

$ guix refresh --type=elpa,cran
gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9
--list-updaters
-L

Enumera los actualizadores disponibles y finaliza (vea la opción previa --type).

Para cada actualizador, muestra la fracción de paquetes que cubre; al final muestra la fracción de paquetes cubiertos por todos estos actualizadores.

Además, guix refresh puede recibir uno o más nombres de paquetes, como en este ejemplo:

$ ./pre-inst-env guix refresh -u emacs idutils gcc@4.8

The command above specifically updates the emacs and idutils packages. The --select option would have no effect in this case. You might also want to update definitions that correspond to the packages installed in your profile:

$ ./pre-inst-env guix refresh -u \
       $(guix package --list-installed | cut -f1)

Cuando se considera la actualización de un paquete, a veces es conveniente conocer cuantos paquetes se verían afectados por la actualización y su compatibilidad debería comprobarse. Para ello la siguiente opción puede usarse cuando se proporcionan uno o más nombres de paquete a guix refresh:

--list-dependent
-l

Enumera los paquetes de nivel superior dependientes que necesitarían una reconstrucción como resultado de la actualización de uno o más paquetes.

See el tipo reverse-package de guix graph, para información sobre cómo visualizar la lista de paquetes que dependen de un paquete.

Sea consciente de que la opción --list-dependent únicamente aproxima las reconstrucciones necesarias como resultado de una actualización. Más reconstrucciones pueden ser necesarias bajo algunas circunstancias.

$ guix refresh --list-dependent flex
Building the following 120 packages would ensure 213 dependent packages are rebuilt:
hop@2.4.0 emacs-geiser@0.13 notmuch@0.18 mu@0.9.9.5 cflow@1.4 idutils@4.6 …

La orden previa enumera un conjunto de paquetes que puede ser construido para comprobar la compatibilidad con una versión actualizada del paquete flex.

--list-transitive

Enumera todos los paquetes de los que uno o más paquetes dependen.

$ guix refresh --list-transitive flex
flex@2.6.4 depends on the following 25 packages: perl@5.28.0 help2man@1.47.6
bison@3.0.5 indent@2.2.10 tar@1.30 gzip@1.9 bzip2@1.0.6 xz@5.2.4 file@5.33 …

La orden previa enumera un conjunto de paquetes que, en caso de cambiar, causarían la reconstrucción de flex.

Las siguientes opciones pueden usarse para personalizar la operación de GnuPG:

--gpg=orden

Use orden como la orden de GnuPG 2.x. Se busca orden en PATH.

--keyring=archivo

Usa archivo como el anillo de claves para claves de proveedoras. archivo debe estar en el formato keybox. Los archivos Keybox normalmente tienen un nombre terminado en .kbx y GNU Privacy Guard (GPG) puede manipular estos archivos (see kbxutil in Using the GNU Privacy Guard, para información sobre una herramienta para manipular archivos keybox).

Cuando se omite esta opción, guix refresh usa ~/.config/guix/upstream/trustedkeys.kbx como el anillo de claves para las firmas de proveedoras. Las firmas OpenPGP son comprobadas contra claves de este anillo; las claves que falten son descargadas a este anillo de claves también (véase --key-download a continuación).

Puede exportar claves de su anillo de claves GPG predeterminado en un archivo keybox usando órdenes como esta:

gpg --export rms@gnu.org | kbxutil --import-openpgp >> mianillo.kbx

Del mismo modo, puede obtener claves de un archivo keybox específico así:

gpg --no-default-keyring --keyring mianillo.kbx \
  --recv-keys 27D586A4F8900854329FF09F1260E46482E63562

See --keyring in Using the GNU Privacy Guard, for more information on GPG’s --keyring option.

--key-download=política

Maneja las claves no encontradas de acuerdo a la política, que puede ser una de:

always

Siempre descarga las claves OpenPGP no encontradas del servidor de claves, y las añade al anillo de claves GnuPG de la usuaria.

never

Nunca intenta descargar claves OpenPGP no encontradas. Simplemente propaga el error.

interactive

Cuando se encuentra un paquete firmado por una clave OpenPGP desconocida, pregunta a la usuaria si descargarla o no. Este es el comportamiento predeterminado.

--key-server=dirección

Use dirección como el servidor de claves OpenPGP cuando se importa una clave pública.

--load-path=directorio

Añade directorio al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles a las herramientas de línea de órdenes.

El actualizador github usa la API de GitHub para consultar nuevas publicaciones. Cuando se usa repetidamente, por ejemplo al comprobar todos los paquetes, GitHub terminará rechazando las peticiones siguientes a través de su API. Por defecto se permiten 60 peticiones por hora a través de su API, y una actualización completa de todos los paquetes de GitHub en Guix necesita más que eso. La identificación con GitHub a través del uso de un identificador de su API (“token”) amplia esos límites. Para usar dicho identificador, establezca la variable de entorno GUIX_GITHUB_TOKEN al valor obtenido a través de https://github.com/settings/tokens o de otra manera.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.7 Invoking guix style

The guix style command helps packagers style their package definitions according to the latest fashionable trends. The command currently provides the following styling rules:

The way package inputs are written is going through a transition (see Referencia de package, for more on package inputs). Until version 1.3.0, package inputs were written using the “old style”, where each input was given an explicit label, most of the time the package name:

(package
  ;; …
  ;; The "old style" (deprecated).
  (inputs `(("libunistring" ,libunistring)
            ("libffi" ,libffi))))

Today, the old style is deprecated and the preferred style looks like this:

(package
  ;; …
  ;; The "new style".
  (inputs (list libunistring libffi)))

Likewise, uses of alist-delete and friends to manipulate inputs is now deprecated in favor of modify-inputs (see Definición de variantes de paquetes, for more info on modify-inputs).

In the vast majority of cases, this is a purely mechanical change on the surface syntax that does not even incur a package rebuild. Running guix style -S inputs can do that for you, whether you’re working on packages in Guix proper or in an external channel.

La sintaxis general es:

guix style [options] package

This causes guix style to analyze and rewrite the definition of package… or, when package is omitted, of all the packages. The --styling or -S option allows you to select the style rule, the default rule being format—see below.

Las opciones disponibles se enumeran a continuación.

--dry-run
-n

Show source file locations that would be edited but do not modify them.

--styling=rule
-S rule

Apply rule, one of the following styling rules:

format

Format the given package definition(s)—this is the default styling rule. For example, a packager running Guix on a checkout (see Ejecución de Guix antes de estar instalado) might want to reformat the definition of the Coreutils package like so:

./pre-inst-env guix style coreutils
inputs

Rewrite package inputs to the “new style”, as described above. This is how you would rewrite inputs of package whatnot in your own channel:

guix style -L ~/my/channel -S inputs whatnot

Rewriting is done in a conservative way: preserving comments and bailing out if it cannot make sense of the code that appears in an inputs field. The --input-simplification option described below provides fine-grain control over when inputs should be simplified.

--load-path=directorio
-L directorio

Añade directorio al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

--expression=expr
-e expr

Style the package expr evaluates to.

Por ejemplo, ejecutando:

guix style -e '(@ (gnu packages gcc) gcc-5)'

styles the gcc-5 package definition.

--input-simplification=policy

When using the inputs styling rule, with ‘-S inputs’, this option specifies the package input simplification policy for cases where an input label does not match the corresponding package name. policy may be one of the following:

silent

Simplify inputs only when the change is “silent”, meaning that the package does not need to be rebuilt (its derivation is unchanged).

safe

Simplify inputs only when that is “safe” to do: the package might need to be rebuilt, but the change is known to have no observable effect.

always

Simplify inputs even when input labels do not match package names, and even if that might have an observable effect.

The default is silent, meaning that input simplifications do not trigger any package rebuild.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.8 Invocación de guix lint

La orden guix lint sirve para ayudar a las desarrolladoras de paquetes a evitar errores comunes y usar un estilo consistente. Ejecuta un número de comprobaciones en un conjunto de paquetes proporcionado para encontrar errores comunes en sus definiciones. Las comprobaciones disponibles incluyen (véase --list-checkers para una lista completa):

synopsis
description

Valida ciertas reglas tipográficas y de estilo en la descripción y sinopsis de cada paquete.

inputs-should-be-native

Identifica entradas que probablemente deberían ser entradas nativas.

source
home-page
mirror-url
github-url
source-file-name

Probe home-page and source URLs and report those that are invalid. Suggest a mirror:// URL when applicable. If the source URL redirects to a GitHub URL, recommend usage of the GitHub URL. Check that the source file name is meaningful, e.g. is not just a version number or “git-checkout”, without a declared file-name (see Referencia de origin).

source-unstable-tarball

Analiza la URL source para determinar si un archivador tar de GitHub se genera de forma automática o es una publicación oficial. Desafortunadamente los archivadores tar de GitHub a veces se regeneran.

derivation

Comprueba que la derivación de los paquetes proporcionados pueden ser calculadas de manera satisfactoria en todos los sistemas implementados (see Derivaciones).

profile-collisions

Comprueba si la instalación de los paquetes proporcionados en el perfil provocaría colisiones. Las colisiones se producen cuando se propagan varios paquetes con el mismo nombre pero una versión diferente o un nombre de archivo del almacén. See propagated-inputs, para más información sobre entradas propagadas.

archival

Comprueba si el código fuente del paquete se encuentra archivado en Software Heritage.

Cuando el código fuente que no se encuentra archivado proviene de un sistema de control de versiones24—por ejemplo, se ha obtenido con git-fetch—, envía a Software Heritage una petición de almacenamiento de manera que se archive cuando sea posible. Esto asegura que las fuentes permanecen disponibles a largo plazo, y que Guix puede usar Software Heritage como respaldo en caso de que el código fuente desapareciese de la máquina que lo almacenaba originalmente. El estado de las peticiones de almacenamiento recientes puede verse en su página web.

Cuando el código fuente es un archivo comprimido que se obtiene con url-fetch, simplemente imprime un mensaje cuando no se encuentra archivado. En el momento de la escritura de este documento, Software Heritage no permite el almacenamiento de archivos comprimidos arbitrarios; estamos trabajando en formas de asegurar que también se archive el código que no se encuentra bajo control de versiones.

Software Heritage limita la tasa de peticiones por dirección IP. Cuando se alcanza dicho límite, guix lint imprime un mensaje y la comprobación archival no hace nada hasta que dicho límite se reinicie.

cve

Informa de vulnerabilidades encontradas en las bases de datos de vulnerabilidades y exposiciones comunes (CVE) del año actual y el pasado publicadas por el NIST de EEUU.

Para ver información acerca de una vulnerabilidad particular, visite páginas como:

donde CVE-YYYY-ABCD es el identificador CVE—por ejemplo, CVE-2015-7554.

Las desarrolladoras de paquetes pueden especificar en las recetas del paquete el nombre y versión en la plataforma común de enumeración (CPE) del paquete cuando el nombre o versión que usa Guix son diferentes, como en este ejemplo:

(package
  (name "grub")
  ;; …
  ;; CPE llama a este paquete "grub2".
  (properties '((cpe-name . "grub2")
                (cpe-version . "2.3"))))

Algunas entradas en la base de datos CVE no especifican a qué versión del paquete hacen referencia, y por lo tanto “permanecen visibles” para siempre. Las desarrolladoras de paquetes que encuentren alertas CVE y verifiquen que pueden ignorarse, pueden declararlas como en este ejemplo:

(package
  (name "t1lib")
  ;; …
  ;; Estas alertas de CVE no aplican y pueden ignorarse
  ;; con seguridad.
  (properties `((lint-hidden-cve . ("CVE-2011-0433"
                                    "CVE-2011-1553"
                                    "CVE-2011-1554"
                                    "CVE-2011-5244")))))
formatting

Avisa de problemas de formato obvios en el código fuente: espacios en blanco al final de las líneas, uso de tabuladores, etc.

input-labels

Report old-style input labels that do not match the name of the corresponding package. This aims to help migrate from the “old input style”. See Referencia de package, for more information on package inputs and input styles. See Invoking guix style, on how to migrate to the new style.

La sintaxis general es:

guix lint opciones paquete

Si no se proporciona ningún paquete en la linea de órdenes, todos los paquetes se comprueban. Las opciones pueden ser cero o más de las siguientes:

--list-checkers
-l

Enumera y describe todas las comprobaciones disponibles que se ejecutarán sobre los paquetes y finaliza.

--checkers
-c

Únicamente activa las comprobaciones especificadas en una lista separada por comas que use los nombres devueltos por --list-checkers.

--exclude
-x

Únicamente desactiva las comprobaciones especificadas en una lista separada por comas que use los nombres devueltos por --list-checkers.

--no-network
-n

Activa únicamente las comprobaciones que no dependen del acceso a internet.

--load-path=directorio
-L directorio

Añade directorio al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles a las herramientas de línea de órdenes.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.9 Invocación de guix size

La orden guix size ayuda a las desarrolladoras de paquetes a perfilar el uso de disco de los paquetes. Es fácil pasar por encima el impacto que produce añadir una dependencia adicional a un paquete, o el impacto del uso de una salida única para un paquete que puede ser dividido fácilmente (see Paquetes con múltiples salidas). Estos son los problemas típicos que guix size puede resaltar.

Se le pueden proporcionar una o más especificaciones de paquete como gcc@4.8 o guile:debug, o un nombre de archivo en el almacén. Considere este ejemplo:

$ guix size coreutils
store item                               total    self
/gnu/store/…-gcc-5.5.0-lib           60.4    30.1  38.1%
/gnu/store/…-glibc-2.27              30.3    28.8  36.6%
/gnu/store/…-coreutils-8.28          78.9    15.0  19.0%
/gnu/store/…-gmp-6.1.2               63.1     2.7   3.4%
/gnu/store/…-bash-static-4.4.12       1.5     1.5   1.9%
/gnu/store/…-acl-2.2.52              61.1     0.4   0.5%
/gnu/store/…-attr-2.4.47             60.6     0.2   0.3%
/gnu/store/…-libcap-2.25             60.5     0.2   0.2%
total: 78.9 MiB

Los elementos del almacén enumerados aquí constituyen la clausura transitiva de Coreutils—es decir, Coreutils y todas sus dependencias, recursivamente—como sería devuelto por:

$ guix gc -R /gnu/store/…-coreutils-8.23

Aquí la salida muestra tres columnas junto a los elementos del almacén. La primera columna, etiquetada “total”, muestra el tamaño en mebibytes (MiB) de la clausura del elemento del almacén—es decir, su propio tamaño sumado al tamaño de todas sus dependencias. La siguiente columna, etiquetada “self”, muestra el tamaño del elemento en sí. La última columna muestra la relación entre el tamaño del elemento en sí frente al espacio ocupado por todos los elementos enumerados.

En este ejemplo, vemos que la clausura de Coreutils ocupa 79 MiB, cuya mayor parte son libc y las bibliotecas auxiliares de GCC para tiempo de ejecución. (Que libc y las bibliotecas de GCC representen una fracción grande de la clausura no es un problema en sí, puesto que siempre están disponibles en el sistema de todas maneras).

Puesto que la orden también acepta nombres de archivo del almacén, comprobar el tamaño del resultado de una construcción es una operación directa:

guix size $(guix system build config.scm)

Cuando los paquetes pasados a guix size están disponibles en el almacén25 consultando al daemon para determinar sus dependencias, y mide su tamaño en el almacén, de forma similar a du -ms --apparent-size (see du invocation in GNU Coreutils).

Cuando los paquetes proporcionados no están en el almacén, guix size informa en base de las sustituciones disponibles (see Sustituciones). Esto hace posible perfilar el espacio en disco incluso de elementos del almacén que no están en el disco, únicamente disponibles de forma remota.

Puede especificar también varios nombres de paquetes:

$ guix size coreutils grep sed bash
store item                               total    self
/gnu/store/…-coreutils-8.24          77.8    13.8  13.4%
/gnu/store/…-grep-2.22               73.1     0.8   0.8%
/gnu/store/…-bash-4.3.42             72.3     4.7   4.6%
/gnu/store/…-readline-6.3            67.6     1.2   1.2%
…
total: 102.3 MiB

En este ejemplo vemos que la combinación de los cuatro paquetes toma 102.3 MiB en total, lo cual es mucho menos que la suma de cada clausura, ya que tienen muchas dependencias en común.

Cuando tenga delante el perfil devuelto por guix size puede preguntarse cuál es la razón de que cierto paquete aparezca en el perfil. Para entenderlo puede usar guix graph --path -t references para mostrar la ruta más corta entre dos paquetes (see Invocación de guix graph).

Las opciones disponibles son:

--substitute-urls=urls

Usa la información de sustituciones de urls. See la misma opción en guix build.

--sort=clave

Ordena las líneas de acuerdo a clave, una de las siguientes opciones:

propio

el tamaño de cada elemento (predeterminada);

closure

el tamaño total de la clausura del elemento.

--map-file=archivo

Escribe un mapa gráfico del uso del disco en formato PNG en el archivo.

Para el ejemplo previo, el mapa tiene esta pinta:

mapa del uso del disco de Coreutils
producido por guix size

Esta opción necesita que la biblioteca Guile-Charting esté instalada y visible en la ruta de búsqueda de módulos Guile. Cuando no es el caso, guix size produce un error al intentar cargarla.

--system=sistema
-s sistema

Considera paquetes para sistema—por ejemplo, x86_64-linux.

--load-path=directorio
-L directorio

Añade directorio al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles a las herramientas de línea de órdenes.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.10 Invocación de guix graph

Packages and their dependencies form a graph, specifically a directed acyclic graph (DAG). It can quickly become difficult to have a mental model of the package DAG, so the guix graph command provides a visual representation of the DAG. By default, guix graph emits a DAG representation in the input format of Graphviz, so its output can be passed directly to the dot command of Graphviz. It can also emit an HTML page with embedded JavaScript code to display a “chord diagram” in a Web browser, using the d3.js library, or emit Cypher queries to construct a graph in a graph database supporting the openCypher query language. With --path, it simply displays the shortest path between two packages. The general syntax is:

guix graph opciones paquete

Por ejemplo, la siguiente orden genera un archivo PDF que representa el GAD para GNU Core Utilities, mostrando sus dependencias en tiempo de construcción:

guix graph coreutils | dot -Tpdf > gad.pdf

La salida es algo así:

Grafo de dependencias de GNU Coreutils

Bonito y pequeño grafo, ¿no?

Puede encontrar más agradable la navegación interactiva del grafo con la orden xdot (del paquete xdot):

guix graph coreutils | xdot -

¡Pero hay más de un grafo! El grafo previo es conciso: es el grafo de los objetos package, omitiendo las entradas implícitas como GCC, libc, grep, etc. Es habitualmente útil tener un grafo conciso así, pero a veces una puede querer ver más detalles. guix graph implementa varios tipos de grafos, lo que le permite seleccionar el nivel de detalle:

package

Este es el tipo por defecto usado en el ejemplo previo. Muestra el GAD de objetos package, excluyendo dependencias implícitas. Es conciso, pero deja fuera muchos detalles.

reverse-package

Esto muestra el GAD inverso de paquetes. Por ejemplo:

guix graph --type=reverse-package ocaml

... emite el grafo de paquetes que dependen explícitamente de OCaml (si también tiene interés en casos donde OCaml es una dependencia implícita, véase reverse-bag a continuación).

Fíjese que esto puede producir grafos inmensos para los paquetes básicos. Si todo lo que quiere saber es el número de paquetes que dependen de uno determinado, use guix refresh --list-dependent (see --list-dependent).

bag-emerged

Este es el GAD del paquete, incluyendo entradas implícitas.

Por ejemplo, la siguiente orden:

guix graph --type=bag-emerged coreutils

... emite este grafo más grande:

Grafo de dependencias detallado de
GNU Coreutils

En la parte inferior del grafo, vemos todas las entradas implícitas de gnu-build-system (see gnu-build-system).

Ahora bien, fíjese que las dependencias de estas entradas implícitas—es decir, las dependencias del lanzamiento inicial (see Lanzamiento inicial)—no se muestran aquí para mantener una salida concisa.

bag

Similar a bag-emerged, pero esta vez incluye todas las dependencias del lanzamiento inicial.

bag-with-origins

Similar a bag, pero también muestra los orígenes y sus dependencias.

reverse-bag

Muestra el GAD inverso de paquetes. Al contrario que reverse-package, también tiene en cuenta las dependencias implícitas. Por ejemplo:

guix graph -t reverse-bag dune

... emite el grafo de tosos los paquetes que dependen de Dune, directa o indirectamente. Ya que Dune es una dependencia implícita de muchos paquetes vía dune-build-system, esto mostrará un gran número de paquetes, mientras que reverse-package mostraría muy pocos si muestra alguno.

derivation

Esta es la representación más detallada: muestra el GAD de derivaciones (see Derivaciones) y elementos simples del almacén. Comparada con las representaciones previas, muchos nodos adicionales son visibles, incluyendo los guiones de construcción, parches, módulos Guile, etc.

Para este tipo de grafo, también es posible pasar un nombre de archivo .drv en vez del nombre del paquete, como en:

guix graph -t derivation $(guix system build -d my-config.scm)
module

Este es el grafo de los módulos de paquete (see Módulos de paquetes). Por ejemplo, la siguiente orden muestra el grafo para el módulo de paquetes que define el paquete guile:

guix graph -t module guile | xdot -

Todos los tipos previos corresponden a las dependencias durante la construcción. El grafo siguiente representa las dependencias en tiempo de ejecución:

references

Este es el grafo de referencias de la salida de un paquete, como lo devuelve guix gc --references (see Invocación de guix gc).

Si la salida del paquete proporcionado no está disponible en el almacén, guix graph intenta obtener la información de dependencias desde las sustituciones.

Aquí también puede proporcionar un nombre de archivo del almacén en vez de un nombre de paquete. Por ejemplo, la siguiente orden produce el grafo de referencias de su perfil (¡el cuál puede ser grande!):

guix graph -t references $(readlink -f ~/.guix-profile)
referrers

Este es el grafo de referentes de la salida de un paquete, como lo devuelve guix gc --referrers (see Invocación de guix gc).

Depende exclusivamente de información en su almacén. Por ejemplo, supongamos que la versión actual de Inkscape está disponible en 10 perfiles en su máquina; guix graph -t referrers inkscape mostrará un grafo cuya raíz es Inkscape y con esos 10 perfiles enlazados a ella.

Puede ayudar a determinar qué impide que un elemento del almacén sea recolectado.

Habitualmente el grafo del paquete por el que tiene interés no entrará en su pantall, y en cualquier caso todo lo que quiere saber es por qué dicho paquete depende de algún paquete que parece no tener relación. La opción --path le indica a guix graph que muestre la ruta más corta entre dos paquetes (o derivaciones, o elementos del almacén, etcétera):

$ guix graph --path emacs libunistring
emacs@26.3
mailutils@3.9
libunistring@0.9.10
$ guix graph --path -t derivation emacs libunistring
/gnu/store/…-emacs-26.3.drv
/gnu/store/…-mailutils-3.9.drv
/gnu/store/…-libunistring-0.9.10.drv
$ guix graph --path -t references emacs libunistring
/gnu/store/…-emacs-26.3
/gnu/store/…-libidn2-2.2.0
/gnu/store/…-libunistring-0.9.10

Sometimes you still want to visualize the graph but would like to trim it so it can actually be displayed. One way to do it is via the --max-depth (or -M) option, which lets you specify the maximum depth of the graph. In the example below, we visualize only libreoffice and the nodes whose distance to libreoffice is at most 2:

guix graph -M 2 libreoffice | xdot -f fdp -

Mind you, that’s still a big ball of spaghetti, but at least dot can render it quickly and it can be browsed somewhat.

Las opciones disponibles son las siguientes:

--type=tipo
-t tipo

Produce un grafo de salida de tipo, donde tipo debe ser uno de los valores enumerados previamente.

--list-types

Enumera los tipos de grafos implementados.

--backend=motor
-b motor

Produce un grafo usando el motor seleccionado.

--list-backends

Enumera los motores de grafos implementados.

Actualmente, los motores disponibles son Graphviz y d3.js.

--path

Muestra la ruta más corta entre dos nodos del tipo especificado por la opción --type. El ejemplo siguiente muestra la ruta más corta entre libreoffice y llvm de acuerdo con las referencias de libreoffice:

$ guix graph --path -t references libreoffice llvm
/gnu/store/…-libreoffice-6.4.2.2
/gnu/store/…-libepoxy-1.5.4
/gnu/store/…-mesa-19.3.4
/gnu/store/…-llvm-9.0.1
--expression=expr
-e expr

Considera el paquete al que evalúa expr

Es útil para hacer una referencia precisa de un paquete concreto, como en este ejemplo:

guix graph -e '(@@ (gnu packages commencement) gnu-make-final)'
--system=sistema
-s sistema

Muestra el grafo para sistema—por ejemplo, i686-linux.

El grafo de dependencias del paquete es altamente independiente de la arquitectura, pero existen algunas partes dependientes de la arquitectura que esta opción le permite visualizar.

--load-path=directorio
-L directorio

Añade directorio al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles a las herramientas de línea de órdenes.

Además de esto, guix graph permite todas las opciones habituales de transformación de paquetes (see Opciones de transformación de paquetes). Esto facilita la visualización del efecto de una transformación de reescritura de grafo como --with-input. Por ejemplo, la siguiente orden muestra el grafo de git una vez que openssl ha sido reemplazado por libressl en todos los nodos del grafo:

guix graph git --with-input=openssl=libressl

¡Tantas posibilidades, tanta diversión!


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.11 Invocación de guix publish

El propósito de guix publish es permitir a las usuarias compartir fácilmente su almacén con otras, quienes pueden usarlo como servidor de sustituciones (see Sustituciones).

When guix publish runs, it spawns an HTTP server which allows anyone with network access to obtain substitutes from it. This means that any machine running Guix can also act as if it were a build farm, since the HTTP interface is compatible with Cuirass, the software behind the ci.guix.gnu.org build farm.

Por seguridad, cada sustitución se firma, permitiendo a las receptoras comprobar su autenticidad e integridad (see Sustituciones). Debido a que guix publish usa la clave de firma del sistema, que es únicamente legible por la administradora del sistema, debe iniciarse como root; la opción --user hace que renuncie a sus privilegios tan pronto como sea posible.

El par claves de firma debe generarse antes de ejecutar guix publish, usando guix archive --generate-key (see Invocación de guix archive).

When the --advertise option is passed, the server advertises its availability on the local network using multicast DNS (mDNS) and DNS service discovery (DNS-SD), currently via Guile-Avahi (see Using Avahi in Guile Scheme Programs).

La sintaxis general es:

guix publish opciones

La ejecución de guix publish sin ningún parámetro adicional lanzará un servidor HTTP en el puerto 8080:

guix publish

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

Una vez el servidor de publicación ha sido autorizado, el daemon puede descargar sustituciones de él. See Obtención de sustiticiones desde otros servidores.

Por defecto, guix publish comprime los archivos al vuelo cuando es necesario. Este modo “al vuelo” es conveniente ya que no necesita configuración y está disponible inmediatamente. No obstante, cuando se proporciona servicio a muchos clientes, se recomienda usar la opción --cache, que activa el almacenamiento en caché de los archivos antes de enviarlos a los clientes—véase a continuación para más detalles. La orden guix weather proporciona una forma fácil de comprobar lo que proporciona un servidor (see Invocación de guix weather).

Además guix publish también sirve como un espejo de acceso por contenido a archivos de fuentes a los que los registros origin hacen referencia (see Referencia de origin). Por ejemplo, si asumimos que guix publish se ejecuta en example.org, la siguiente URL devuelve directamente el archivo hello-2.10.tar.gz con el hash SHA256 proporcionado (representado en formato nix-base32, see Invocación de guix hash).

http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1…ndq1i

Obviamente estas URL funcionan solamente para archivos que se encuentran en el almacén; en otros casos devuelven un 404 (“No encontrado”).

Los log de construcción están disponibles desde URL /log como:

http://example.org/log/gwspk…-guile-2.2.3

Cuando guix-daemon está configurado para almacenar comprimidos los log de construcción, como sucede de forma predeterminada (see Invocación de guix-daemon), las URL /log devuelven los log igualmente comprimidos, con un Content-Type adecuado y/o una cabecera Content-Encoding. Recomendamos ejecutar guix-daemon con --log-compression=gzip ya que los navegadores Web pueden extraer el contenido automáticamente, lo cual no es el caso con la compresión bzip2.

Las siguientes opciones están disponibles:

--port=puerto
-p puerto

Escucha peticiones HTTP en puerto.

--listen=dirección

Escucha en la interfaz de red de la dirección. El comportamiento predeterminado es aceptar conexiones de cualquier interfaz.

--user=usuaria
-u usuaria

Cambia los privilegios a los de usuaria tan pronto como sea posible—es decir, una vez el socket del servidor esté abierto y la clave de firma haya sido leída.

--compression[=método[:nivel]]
-C [método[:nivel]]

Compress data using the given method and level. method is one of lzip, zstd, and gzip; when method is omitted, gzip is used.

Cuando el nivel es cero, desactiva la compresión. El rango 1 a 9 corresponde a distintos niveles de compresión gzip: 1 es el más rápido, y 9 es el mejor (intensivo a nivel de CPU). El valor predeterminado es 3.

Usually, lzip compresses noticeably better than gzip for a small increase in CPU usage; see benchmarks on the lzip Web page. However, lzip achieves low decompression throughput (on the order of 50 MiB/s on modern hardware), which can be a bottleneck for someone who downloads over a fast network connection.

The compression ratio of zstd is between that of lzip and that of gzip; its main advantage is a high decompression speed.

A menos que se use --cache, la compresión ocurre al vuelo y los flujos comprimidos no se almacenan en caché. Por tanto, para reducir la carga en la máquina que ejecuta guix publish, puede ser una buena idea elegir un nivel de compresión bajo, ejecutar guix publish detrás de una pasarela con caché o usar --cache. El uso de --cache tiene la ventaja de que permite a guix publish añadir la cabecera HTTP Content-Length a sus respuestas.

Se puede repetir esta opción, en cuyo caso cada sustitución se comprime usando todos los métodos seleccionados, y todos son anunciados. Esto es útil cuando las usuarias pueden no implementar todos los métodos de compresión: pueden seleccionar el que implementan.

--cache=directorio
-c directorio

Almacena en caché los archivos y metadatos (URL .narinfo) en directorio y únicamente proporciona archivos que están en la caché.

Cuando se omite esta opción, los archivos y metadatos se crean al vuelo. Esto puede reducir el ancho de banda disponible, especialmente cuando la compresión está activa, ya que se puede llegar al límite de la CPU. Otra desventaja del modo predeterminado es que la longitud de los archivos no se conoce con anterioridad, por lo que guix publish no puede añadir la cabecera HTTP Content-Length a sus respuestas, lo que a su vez previene que los clientes conozcan la cantidad de datos a descargar.

De manera contraria, cuando se usa --cache, la primera petición de un elemento del almacén (a través de una URL .narinfo) inicia un proceso en segundo plano para cocinar el archivo—calcular su .narinfo y comprimirlo, en caso necesario. Una vez el archivo está alojado en la caché de directorio, las siguientes peticiones obtendrán un resultado satisfactorio y se ofrecerá el contenido directamente desde la caché, lo que garantiza que los clientes obtienen el mejor ancho de banda posible.

La primera petción de .narinfo devuelve no obstante el código 200, en el caso de que el elemento del almacén sea “lo suficientemente pequeño”, es decir que su tamaño sea inferior al límite de bajo el que se ignora la caché—véase la opción --cache-bypass-threshold a continuación. De este modo, los clientes no deben esperar hasta que el archivo se haya cocinado. Con elementos del almacén de mayor tamaño la primera petición .narinfo devuelve el código 404, lo que significa que los clientes deben esperar hasta que el archivo se haya cocinado.

El proceso de “cocinado” se realiza por hilos de trabajo. Por defecto, se crea un hilo por núcleo de la CPU, pero puede ser personalizado. Véase --workers a continuación.

Cuando se usa --ttl, las entradas en caché se borran automáticamente cuando hayan expirado.

--workers=N

Cuando se usa --cache, solicita la creación de N hilos de trabajo para “cocinar” archivos.

--ttl=ttl

Produce cabeceras HTTP Cache-Control que anuncian un tiempo-de-vida (TTL) de ttl. ttl debe indicar una duración: 5d significa 5 días, 1m significa un mes, etc.

Esto permite a la usuaria de Guix mantener información de sustituciones en la caché durante ttl. No obstante, fíjese que guix publish no garantiza en sí que los elementos del almacén que proporciona de hecho permanezcan disponibles hasta que ttl expire.

Adicionalmente, cuando se usa --cache, las entradas en caché que no hayan sido accedidas en ttl y no tengan un elemento correspondiente en el almacén pueden ser borradas.

--negative-ttl=ttl

Similarly produce Cache-Control HTTP headers to advertise the time-to-live (TTL) of negative lookups—missing store items, for which the HTTP 404 code is returned. By default, no negative TTL is advertised.

This parameter can help adjust server load and substitute latency by instructing cooperating clients to be more or less patient when a store item is missing.

--cache-bypass-threshold=tamaño

Cuando se usa en conjunto con la opción --cache, los elementos del almacén cuyo tamaño sea inferior a tamaño están disponibles de manera inmediata, incluso cuando no están todavía en la caché. tamaño es el número de bytes, o se puedem usar sufijos como M para megabytes, etcétera. El valor predeterminado es 10M.

La opción de omisión de la cache le permite reducir la latencia de publicación a los clientes a expensas de un posible incremento en el uso de E/S y procesador en el lado del servidor: dependiendo de los patrones de acceso de los clientes, dichos elementos del almacén pueden ser cocinados varias veces hasta que una copia se encuentre disponible en la caché.

Incrementar el valor límite puede ser útil para servidores que tengan pocas usuarias, o para garantizar que dichas usuarias obtienen sustituciones incluso con elementos del almacén que no son populares.

--nar-path=ruta

Usa ruta como el prefijo para las URL de los archivos “nar” (see archivadores normalizados).

Por defecto, los archivos nar se proporcionan en una URL como /nar/gzip/…-coreutils-8.25. Esta opción le permite cambiar la parte /nar por ruta.

--public-key=archivo
--private-key=archivo

Usa los archivos específicos como el par de claves pública y privada usadas para firmar los elementos del almacén publicados.

Los archivos deben corresponder al mismo par de claves (la clave privada se usa para la firma y la clave pública simplemente se anuncia en los metadatos de la firma). Deben contener claves en el formato canónico de expresiones-S como el producido por guix archive --generate-key (see Invocación de guix archive). Por defecto, se usan /etc/guix/signing-key.pub y /etc/guix/signing-key.sec.

--repl[=puerto]
-r [puerto]

Lanza un servidor REPL Guile (see REPL Servers in GNU Guile Reference Manual) en puerto (37146 por defecto). Esto se usa principalmente para la depuración de un servidor guix publish en ejecución.

Activar guix publish en el sistema Guix consiste en solo una línea: simplemente instancie un servicio guix-publish-service-type en el campo services de su declaración del sistema operativo operating-system (see guix-publish-service-type)

Si en vez de eso ejecuta Guix en una distribución distinta, siga estas instrucciones:


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.12 Invocación de guix challenge

¿Los binarios que proporciona este servidor realmente corresponden al código fuente que dice construir? ¿Es determinista el proceso de construcción de un paquete? Estas son las preguntas que la orden guix challenge intenta responder.

La primera es obviamente una cuestión importante: antes de usar un servidor de sustituciones (see Sustituciones), es importante haber verificado que proporciona los binarios correctos, y por tanto ponerlo a prueba26. La segunda es lo que permite la primera: si las construcciones de los paquetes son deterministas, construcciones independientes deberían emitir el mismo resultado, bit a bit; si el servidor proporciona un binario diferente al obtenido localmente, o bien está corrupto o bien tiene intenciones perniciosas.

Sabemos que el hash que se muestra en los nombres de archivo en /gnu/store es el hash de todas las entradas del proceso que construyó el archivo o directorio—compiladores, bibliotecas, guiones de construcción, etc. (see Introducción). Asumiendo procesos de construcción deterministas, un nombre de archivo del almacén debe corresponder exactamente a una salida de construcción. guix challenge comprueba si existe, realmente, una asociación unívoca comparando la salida de la construcción de varias construcciones independientes de cualquier elemento del almacén proporcionado.

La salida de la orden muestra algo así:

$ guix challenge --substitute-urls="https://ci.guix.gnu.org https://guix.example.org"
updating list of substitutes from 'https://ci.guix.gnu.org'... 100.0%
updating list of substitutes from 'https://guix.example.org'... 100.0%
/gnu/store/…-openssl-1.0.2d contents differ:
  local hash: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
  https://ci.guix.gnu.org/nar/…-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
  https://guix.example.org/nar/…-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim
  differing files:
    /lib/libcrypto.so.1.1
    /lib/libssl.so.1.1

/gnu/store/…-git-2.5.0 contents differ:
  local hash: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha
  https://ci.guix.gnu.org/nar/…-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f
  https://guix.example.org/nar/…-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
  differing file:
    /libexec/git-core/git-fsck

/gnu/store/…-pius-2.1.1 contents differ:
  local hash: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
  https://ci.guix.gnu.org/nar/…-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
  https://guix.example.org/nar/…-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs
  differing file:
    /share/man/man1/pius.1.gz

…

6,406 elementos del almacén fueron analizados:
  - 4,749 (74.1%) fueron idénticos
  - 525 (8.2%) fueron diferentes
  - 1,132 (17.7%) no arrojaron resultados concluyentes

En este ejemplo, guix challenge primero recorre el almacén para determinar el conjunto de derivaciones construidas localmente—en oposición a elementos del almacén que fueron descargados de un servidor de sustituciones—y consulta a todos los servidores de sustituciones. Una vez hecho informa de los elementos del almacén para los cuales los servidores obtuvieron un resultado diferente de el obtenido en la construcción local.

As an example, guix.example.org always gets a different answer. Conversely, ci.guix.gnu.org agrees with local builds, except in the case of Git. This might indicate that the build process of Git is non-deterministic, meaning that its output varies as a function of various things that Guix does not fully control, in spite of building packages in isolated environments (see Características). Most common sources of non-determinism include the addition of timestamps in build results, the inclusion of random numbers, and directory listings sorted by inode number. See https://reproducible-builds.org/docs/, for more information.

Para encontrar cuál es el problema con este binario Git, la aproximación más fácil es ejecutar:

guix challenge git \
  --diff=diffoscope \
  --substitute-urls="https://ci.guix.gnu.org https://guix.example.org"

Esto invoca automáticamente diffoscope, que muestra información detallada sobre los archivos que son diferentes.

De manera alternativa, se puede hacer algo parecido a esto (see Invocación de guix archive):

$ wget -q -O - https://ci.guix.gnu.org/nar/lzip/…-git-2.5.0 \
   | lzip -d | guix archive -x /tmp/git
$ diff -ur --no-dereference /gnu/store/…-git.2.5.0 /tmp/git

This command shows the difference between the files resulting from the local build, and the files resulting from the build on ci.guix.gnu.org (see Comparing and Merging Files in Comparing and Merging Files). The diff command works great for text files. When binary files differ, a better option is Diffoscope, a tool that helps visualize differences for all kinds of files.

Una vez haya realizado este trabajo, puede determinar si las diferencias son debidas a un procedimiento de construcción no-determinista o a un servidor con intenciones ocultas. Intentamos duramente eliminar las fuentes de indeterminismo en los paquetes para facilitar la verificación de sustituciones, pero por supuesto es un proceso que implica no solo a Guix, sino a una gran parte de la comunidad del software libre. Entre tanto, guix challenge es una herramienta para ayudar a afrontar el problema.

If you are writing packages for Guix, you are encouraged to check whether ci.guix.gnu.org and other substitute servers obtain the same build result as you did with:

$ guix challenge paquete

donde paquete es una especificación de paquete como guile@2.0 o glibc:debug.

La sintaxis general es:

guix challenge opciones [paquetes…]

Cuando se encuentra una diferencia entre el hash de un elemento construido localmente y el proporcionado por un servidor de sustituciones; o entre las sustituciones proporcionadas por distintos servidores, esto es mostrado como en el ejemplo previo y el código de salida es 2 (otros valores código de salida distintos de cero denominan otros tipos de error).

La única opción de importancia es:

--substitute-urls=urls

Considera urls la lista separada por espacios de URL de fuentes de sustituciones con las que realizar la comparación.

--diff=modo

Muestra las diferencias encontradas de acuerdo con modo, uno de los siguientes:

simple (el predeterminado)

Muestra la lista de archivos que son diferentes.

diffoscope
orden

Invoca Diffoscope y le proporciona los dos directorios cuyo contenido es diferente.

Cuando orden es una ruta absoluta, ejecuta orden en vez de Diffoscope.

none

No muestra más detalles sobre las diferencias.

Por tanto, a menos que se proporcione --diff=none, guix challenge descarga los contenidos de los elementos del almacén de los servidores de sustituciones proporcionados para poder compararlos.

--verbose
-v

Muestra detalles sobre coincidencias (contenidos idénticos) además de información sobre las discrepancias.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.13 Invocación de guix copy

La orden guix copy copia elementos del almacén de una máquina al de otra a través de una conexión de shell seguro (SSH)27. Por ejemplo, la siguiente orden copia el paquete coreutils, el perfil de la usuaria y todas sus dependencias a dirección, ingresando en el sistema como usuaria:

guix copy --to=user@host \
          coreutils $(readlink -f ~/.guix-profile)

Si alguno de los elementos del almacén a copiar ya están presentes en dirección, no se envían realmente.

La siguiente orden obtiene libreoffice y gimp de dirección, asumiendo que estén disponibles allí:

guix copy --from=dirección libreoffice gimp

La conexión SSH se establece usando el cliente Guile-SSH, que es compatible con OpenSSH: tiene en cuenta ~/.ssh/known_hosts y ~/.ssh/config, y usa el agente SSH para la identificación.

La clave usada para firmar los elementos enviados debe estar aceptada por la máquina remota. Del mismo modo, la clave usada por la máquina remota para firmar los elementos recibidos debe estar en /etc/guix/acl de modo que sea aceptada por su propio daemon. See Invocación de guix archive, para más información sobre la verificación de elementos del almacén.

La sintaxis general es:

guix copy [--to=spec|--from=spec] elementos

Siempre debe especificar una de las siguientes opciones:

--to=spec
--from=spec

Especifica la máquina a la que mandar o desde la que recibir. spec debe ser una especificación SSH como example.org, carlos@example.org, or carlos@example.org:2222.

Los elementos pueden ser tanto nombres de paquetes, como gimp, como elementos del almacén, como /gnu/store/…-idutils-4.6.

Cuando se especifica el nombre del paquete a enviar, primero se construye si es necesario, a menos que se use --dry-run. Se aceptan las opciones comunes de construcción (see Opciones comunes de construcción).


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.14 Invocación de guix container

Nota: En la versión df72ba9, esta herramienta es experimental. La interfaz está sujeta a cambios radicales en el futuro.

The purpose of guix container is to manipulate processes running within an isolated environment, commonly known as a “container”, typically created by the guix shell (see Invoking guix shell) and guix system container (see Invocación de guix system) commands.

La sintaxis general es:

guix container acción opciones

acción especifica la operación a realizar con el contenedor, y opcines especifica los parámetros específicos del contexto para la acción.

Las siguientes acciones están disponibles:

exec

Ejecute una orden en el contexto de un contenedor en ejecución.

La sintaxis es:

guix container exec pid programa parámetros

pid especifica el ID del proceso del contenedor en ejecución. programa especifica el nombre del archivo ejecutable dentro del sistema de archivos raíz del contenedor. parámetros son opciones adicionales que se pasarán a programa.

La siguiente orden lanza un shell interactivo de ingreso al sistema dentro de un contenedor del sistema, iniciado por guix system container, y cuyo ID de proceso es 9001:

guix container exec 9001 /run/current-system/profile/bin/bash --login

Fíjese que el pid no puede ser el proceso creador del contenedor. Debe ser el PID 1 del contenedor o uno de sus procesos hijos.


Next: , Previous: , Up: Utilidades   [Contents][Index]

9.15 Invocación de guix weather

De manera ocasional tendrá un mal día al no estar las sustituciones disponibles y le toque construir los paquetes a usted misma (see Sustituciones). La orden guix weather informa de la disponibilidad de sustituciones en los servidores especificados de modo que pueda tener una idea sobre cómo será su día hoy. A veces puede ser una información útil como usuaria, pero es principalmente útil para quienes ejecuten guix publish (see Invocación de guix publish).

Esta es una ejecución de ejemplo:

$ guix weather --substitute-urls=https://guix.example.org
computing 5,872 package derivations for x86_64-linux...
looking for 6,128 store items on https://guix.example.org..
updating list of substitutes from 'https://guix.example.org'... 100.0%
https://guix.example.org
  43.4% substitutes available (2,658 out of 6,128)
  7,032.5 MiB of nars (compressed)
  19,824.2 MiB on disk (uncompressed)
  0.030 seconds per request (182.9 seconds in total)
  33.5 requests per second

  9.8% (342 out of 3,470) of the missing items are queued
  867 queued builds
      x86_64-linux: 518 (59.7%)
      i686-linux: 221 (25.5%)
      aarch64-linux: 128 (14.8%)
  build rate: 23.41 builds per hour
      x86_64-linux: 11.16 builds per hour
      i686-linux: 6.03 builds per hour
      aarch64-linux: 6.41 builds per hour

Como puede ver, informa de la fracción de todos los paquetes para los cuales hay sustituciones en el servidor—independientemente de que las sustituciones estén activadas, e independientemente de si la clave de firma del servidor está autorizada. También informa del tamaño de los archivos comprimidos (“nar”) proporcionados por el servidor, el tamaño que los elementos correspondientes del almacén ocupan en el almacén (asumiendo que la deduplicación está apagada) y el caudal de proceso del servidor. La segunda parte proporciona estadísticas de integración continua (CI), si el servidor lo permite. Además, mediante el uso de la opción --coverage, guix weather puede enumerar sustituciones de paquetes “importantes” que no se encuentren en el servidor (véase más adelante).

Para conseguirlo, guix weather consulta los metadatos HTTP(S) (narinfos) de todos los elementos relevantes del almacén. Como guix challenge, ignora las firmas en esas sustituciones, lo cual es inocuo puesto que la orden únicamente obtiene estadísticas y no puede instalar esas sustituciones.

La sintaxis general es:

guix weather opciones… [paquetes…]

Cuando se omite paquetes, guix weather comprueba la disponibilidad de sustituciones para todos los paquetes, o para aquellos especificados con la opción --manifest; en otro caso considera únicamente los paquetes especificados. También es posible consultar tipos de sistema específicos con --system. guix weather termina con un código de salida distinto a cero cuando la fracción de sustituciones disponibles se encuentra por debajo del 100%.

Las opciones disponibles se enumeran a continuación.

--substitute-urls=urls

urls es la lista separada por espacios de URL de servidores de sustituciones a consultar. Cuando se omite esta opción, el conjunto predeterminado de servidores de sustituciones es el consultado.

--system=sistema
-s sistema

Consulta sustituciones para sistema—por ejemplo, aarch64-linux. Esta opción se puede repetir, en cuyo caso guix weather consultará las sustituciones para varios tipos de sistema.

--manifest=archivo

En vez de consultar las sustituciones de todos los paquetes, consulta únicamente los especificados en archivo. archivo debe contener un manifiesto, como el usado en la opción -m de guix package (see Invocación de guix package).

Esta opción puede repetirse varias veces, en cuyo caso los manifiestos se concatenan.

--coverage[=numero]
-c [numero]

Informa de la cobertura de sustituciones para paquetes: enumera paquetes con al menos número dependientes (cero por omisión) para los cuales no haya sustituciones disponibles. Los paquetes dependientes en sí no se enumeran: si b depende de a y a no tiene sustituciones disponibles, únicamente se muestra a, aunque b normalmente no tenga sustituciones tampoco. El resultado es más o menos así:

$ guix weather --substitute-urls=https://ci.guix.gnu.org https://bordeaux.guix.gnu.org -c 10
computing 8,983 package derivations for x86_64-linux...
looking for 9,343 store items on https://ci.guix.gnu.org https://bordeaux.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org https://bordeaux.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org https://bordeaux.guix.gnu.org
  64.7% substitutes available (6,047 out of 9,343)
…
2502 packages are missing from 'https://ci.guix.gnu.org https://bordeaux.guix.gnu.org' for 'x86_64-linux', among which:
    58  kcoreaddons@5.49.0      /gnu/store/…-kcoreaddons-5.49.0
    46  qgpgme@1.11.1           /gnu/store/…-qgpgme-1.11.1
    37  perl-http-cookiejar@0.008  /gnu/store/…-perl-http-cookiejar-0.008
    …

What this example shows is that kcoreaddons and presumably the 58 packages that depend on it have no substitutes at ci.guix.gnu.org; likewise for qgpgme and the 46 packages that depend on it.

Si es una desarrolladora Guix, o si se encuentra a cargo de esta granja de construcción, probablemente quiera inspeccionar estos paquetes con más detalle: simplemente puede que su construcción falle.

--display-missing

Muestra los elementos del almacén para los que faltan las sustituciones.


Previous: , Up: Utilidades   [Contents][Index]

9.16 Invocación de guix processes

La orden guix processes puede ser útil a desarrolladoras y administradoras de sistemas, especialmente en máquinas multiusuaria y en granjas de construcción: enumera las sesiones actuales (conexiones al daemon), así como información sobre los procesos envueltos28. A continuación puede verse un ejemplo de la información que devuelve:

$ sudo guix processes
SessionPID: 19002
ClientPID: 19090
ClientCommand: guix shell python

SessionPID: 19402
ClientPID: 19367
ClientCommand: guix publish -u guix-publish -p 3000 -C 9 …

SessionPID: 19444
ClientPID: 19419
ClientCommand: cuirass --cache-directory /var/cache/cuirass …
LockHeld: /gnu/store/…-perl-ipc-cmd-0.96.lock
LockHeld: /gnu/store/…-python-six-bootstrap-1.11.0.lock
LockHeld: /gnu/store/…-libjpeg-turbo-2.0.0.lock
ChildPID: 20495
ChildCommand: guix offload x86_64-linux 7200 1 28800
ChildPID: 27733
ChildCommand: guix offload x86_64-linux 7200 1 28800
ChildPID: 27793
ChildCommand: guix offload x86_64-linux 7200 1 28800

En este ejemplo vemos que guix-daemon tiene tres clientes: guix environment, guix publish y la herramienta de integración continua Cuirass; sus identificadores de proceso (PID) se muestran en el campo ClientPID. El campo SessionPID proporciona el PID del subproceso de guix-daemon de cada sesión en particular.

The LockHeld fields show which store items are currently locked by this session, which corresponds to store items being built or substituted (the LockHeld field is not displayed when guix processes is not running as root). Last, by looking at the ChildPID and ChildCommand fields, we understand that these three builds are being offloaded (see Configuración de delegación del daemon).

La salida está en formato Recutils por lo que podemos usar la útil orden recsel para seleccionar sesiones de interés (see Selection Expressions in GNU recutils manual). Como un ejemplo, la siguiente orden muestra la línea de órdenes y el PID del cliente que inició la construcción de un paquete Perl:

$ sudo guix processes | \
    recsel -p ClientPID,ClientCommand -e 'LockHeld ~ "perl"'
ClientPID: 19419
ClientCommand: cuirass --cache-directory /var/cache/cuirass …

Additional options are listed below.

--format=formato
-f formato

Produce salida en el formato especificado, uno de:

recutils

The default option. It outputs a set of Session recutils records that include each ChildProcess as a field.

normalized

Normalize the output records into record sets (see Record Sets in GNU recutils manual). Normalizing into record sets allows joins across record types. The example below lists the PID of each ChildProcess and the associated PID for Session that spawned the ChildProcess where the Session was started using guix build.

$ guix processes --format=normalized | \
    recsel \
    -j Session \
    -t ChildProcess \
    -p Session.PID,PID \
    -e 'Session.ClientCommand ~ "guix build"'
PID: 4435
Session_PID: 4278

PID: 4554
Session_PID: 4278

PID: 4646
Session_PID: 4278

Next: , Previous: , Up: Top   [Contents][Index]

10 Configuración del sistema

El sistema Guix permite un mecanismo de configuración del sistema completo consistente. Con esto queremos decir que todos los aspectos de la configuración global del sistema—como