Manual de referencia de GNU Guix

Índice general

Siguiente: , Subir: (dir)   [Índice general][Índice]

GNU Guix

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

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


Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

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 (véase Instalación), o puede usarse como un sistema operativo en sí mismo, el sistema Guix2. Véase Distribución GNU.


Siguiente: , Subir: Introducción   [Índice general][Índice]

1.1 Gestión de software con Guix

Guix provides a command-line package management interface (véase Gestión de paquetes), tools to help with software development (véase Desarrollo), command-line utilities for more advanced usage (véase Utilidades), as well as Scheme programming interfaces (véase Interfaz programática). Su daemon de construcción es responsable de la construcción de paquetes en delegación de las usuarias (véase Preparación del daemon) y de la descarga de binarios preconstruidos de fuentes autorizadas (véase 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 (véase Definición de paquetes) y hacerlas disponibles como módulos independientes de paquetes (véase 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 (véase 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 (véase 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 (véase 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 (véase Características).


Anterior: , Subir: Introducción   [Índice general][Índice]

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 (véase Instalación del sistema), pero también es posible instalar Guix como un gestor de paquetes sobre un sistema GNU/Linux existente (véase 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 (véase 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 (véase hurd-vm-service-type). ¡Véase Contribuir para informarse sobre cómo ayudar!

mips64el-linux (obsoleta)

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.

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 (véase Sustituciones), and some packages may fail to build (véase 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 (véase Configuración del sistema). El sistema Guix usa el núcleo Linux-libre, el sistema de inicialización Shepherd (véase Introducción en 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 and powerpc64le-linux.

Para información sobre el transporte a otras arquitecturas o núcleos, véase Transportar.

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


Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

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 (véase 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.


Siguiente: , Subir: Instalación   [Índice general][Índice]

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, véase Configuración de la aplicación para obtener información adicional que pueda necesitar, ¡y Empezando para sus primeros pasos!

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

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

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

    $ wget https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz.sig
    $ gpg --verify guix-binary-1.3.0.x86_64-linux.tar.xz.sig
    

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

    $ wget 'https://sv.gnu.org/people/viewgpg.php?user_id=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-1.3.0.x86_64-linux.tar.xz
    # mv var/guix /var/ && mv gnu /
    

    Esto crea /gnu/store (véase 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 (véase 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 (véase 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
    

    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 (véase Other Info Directories en GNU Texinfo, para más detalles sobre cómo cambiar la ruta de búsqueda de Info).

  7. Para usar sustituciones de ci.guix.gnu.org o uno de sus espejos (véase Sustituciones), debe autorizarlas:
    # guix archive --authorize < \
         ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub
    
  8. Cada usuaria puede necesitar dar algunos pasos adicionales para preparar su entorno de Guix para el uso diario, véase 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

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


Siguiente: , Anterior: , Subir: Instalación   [Índice general][Índice]

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 (véase localstatedir en 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 (véase El almacén).


Siguiente: , Anterior: , Subir: Instalación   [Índice general][Índice]

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"

Véase Parallel Test Harness en 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 (véase 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 (véase 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.


Siguiente: , Anterior: , Subir: Instalación   [Índice general][Índice]

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.


Siguiente: , Subir: Preparación del daemon   [Índice general][Índice]

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 (véase 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 (véase --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 (véase 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:

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 (véase Derivaciones) o para sustituciones (véase 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.


Siguiente: , Anterior: , Subir: Preparación del daemon   [Índice general][Índice]

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 (véase 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 "armocho.example.org")
        (systems (list "aarch64-linux"))
        (host-key "ssh-rsa AAAAB3Nza…")
        (user "alicia")
        (private-key
         (string-append (getenv "HOME")
                        "/.ssh/identidad-para-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 (véase Guile-Avahi en 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 (véase Converting keys en 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 (véase 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

Anterior: , Subir: Preparación del daemon   [Índice general][Índice]

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.


Siguiente: , Anterior: , Subir: Instalación   [Índice general][Índice]

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

Para detalles obre como configurarlo, véase 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 (véase 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 (véase 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 (véase --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. Véase 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 (véase 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 (véase 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 (véase El almacén).

--substitute-urls=urls

Considera urls la lista separada por espacios predeterminada de URLs de sustituciones de fuentes. Cuando se omite esta opción, se usa ‘https://ci.guix.gnu.org’.

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

Véase 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 (véase 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é. Véase 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 (véase 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 (véase 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 (véase --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 (véase --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 (véase 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 (véase 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.

A menos que se use --lose-logs, todos los log de construcción se mantienen en localstatedir. Para ahorrar espacio, el daemon automáticamente los comprime con bzip2 por defecto.

--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 (véase 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. Véase 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 (véase 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.


Siguiente: , Anterior: , Subir: Instalación   [Índice general][Índice]

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 917 MiB. Alternatively, the glibc-utf8-locales is smaller but limited to a few UTF-8 locales.

La variable GUIX_LOCPATH juega un rol similar a LOCPATH (véase LOCPATH en 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 (véase Selector de servicios de nombres en 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 (véase NSS Configuration File en 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

La mayoría de aplicaciones gráficas usan Fontconfig para encontrar y cargar tipografías y realizar la renderización del lado del cliente X11. El paquete fontconfig en Guix busca tipografías en $HOME/.guix-profile por defecto. Por tanto, para permitir a aplicaciones gráficas instaladas con Guix mostrar tipografías, tiene que instalar las tipografías también con Guix. Paquetes esenciales de tipografías incluyen gs-fonts, font-dejavu y 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 (véase 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. Véase 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 (véase Init File en The GNU Emacs Manual).


Anterior: , Subir: Instalación   [Índice general][Índice]

2.7 Actualizar Guix

Para actualizar Guix ejecute:

guix pull

Véase 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 (véase guix system reconfigure).


Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

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, véase Instalación.


Siguiente: , Subir: Instalación del sistema   [Índice general][Índice]

3.1 Limitaciones

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

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

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. Véase Contribuir, para más información.


Siguiente: , Anterior: , Subir: Instalación del sistema   [Índice general][Índice]

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 (véase 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.


Siguiente: , Anterior: , Subir: Instalación del sistema   [Índice general][Índice]

3.3 Instalación desde memoria USB y DVD

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

x86_64-linux

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

i686-linux

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

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

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

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

$ wget https://sv.gnu.org/people/viewgpg.php?user_id=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-1.3.0.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-1.3.0.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.

Véase 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).


Siguiente: , Anterior: , Subir: Instalación del sistema   [Índice general][Índice]

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 (véase 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” (véase 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 (véase 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.


Siguiente: , Anterior: , Subir: Instalación del sistema   [Índice general][Índice]

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 (véase 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. ¡Véase Tras la instalación del sistema para ver cómo proceder a continuación!


Siguiente: , Anterior: , Subir: Instalación del sistema   [Índice general][Índice]

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 (véase Instalación gráfica guiada).

El sistema de instalación proporciona consolas de administración (“root”) en los terminales virtuales (TTY) 3 a 6; pulse ctrl-alt-f3, ctrl-alt-f4 y sucesivas teclas para abrirlas. Incluye muchas herramientas comunes necesarias para la instalación del sistema. Pero es también un sistema Guix completo, lo que significa que puede instalar paquetes adicionales, en caso de necesitarlos, mediante el uso de guix package (véase Invocación de guix package).


Siguiente: , Subir: Instalación manual   [Índice general][Índice]

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 (véase Overview en 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 (véase BIOS installation en 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. Véase 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)8. 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(véase 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 (véase 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

Si en vez de eso planea cifrar la partición raíz, puede usar las herramientas Crypsetup/LUKS para hacerlo (véase man cryptsetup para más información). Asumiendo que quiere almacenar la partición raíz en /dev/sda2, la secuencia de ordenes sería más o menos así:

cryptsetup luksFormat /dev/sda2
cryptsetup open --type luks /dev/sda1 mi-particion
mkfs.ext4 -L mi-raiz /dev/mapper/mi-particion

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.

Finalmente, si planea usar una o más particiones de intercambio (véase swap space en The GNU C Library Reference Manual), asegúrese de inicializarla con mkswap. Asumiendo que tuviese una partición de intercambio en /dev/sda3, ejecutaría:

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ía9:

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


Anterior: , Subir: Instalación manual   [Índice general][Índice]

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.

Después debe editar un archivo y proporcionar la declaración de sistema operativo a instalar. Para dicho fin, el sistema de instalación viene con tres editores de texto. Recomendamos GNU nano (véase GNU nano Manual), que permite el resaltado de sintaxis y correspondencia de paréntesis; los otros editores son GNU Zile (un clon de Emacs) y nvi (un clon del editor vi original de BSD). Le recomendamos encarecidamente almacenar ese archivo en el sistema de archivos raíz, digamos, como /mnt/etc/config.scm. En caso de no hacerlo, habrá perdido su configuración del sistema una vez arranque en el sistema recién instalado.

Véase 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, véase 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 (véase contraseñas de cuentas de usuaria). ¡Véase Tras la instalación del sistema para proceder a continuación!


Siguiente: , Anterior: , Subir: Instalación del sistema   [Índice general][Índice]

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 (véase Invocación de guix system). Recomendamos realizarlo de manera regular de modo que su sistema incluya las últimas actualizaciones de seguridad (véase 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.

Ahora, véase Empezando, ¡y únase a nosotras en #guix en la red IRC de Libera Chat o en guix-devel@gnu.org para compartir su experiencia!


Siguiente: , Anterior: , Subir: Instalación del sistema   [Índice general][Índice]

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 (véase Instalación desde memoria USB y DVD).
  2. Cree una imagen de disco que contendrá el sistema instalado. Para crear una imagen de disco con formato qcow2, use la orden qemu-img:
    qemu-img create -f qcow2 guix-system.img 50G
    

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

  3. Arranque la imagen de instalación USB en una máquina virtual:
    qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
      -nic user,model=virtio-net-pci -boot menu=on,order=d \
      -drive file=guix-system.img \
      -drive media=cdrom,file=guix-system-install-1.3.0.sistema.iso
    

    -enable-kvm es opcional, pero mejora el rendimiento significativamente, véase Ejecutar Guix en una máquina virtual.

  4. Ahora es root en la VM, prosiga con el procedimiento de instalación. Véase 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. Véase Ejecutar Guix en una máquina virtual, para información sobre cómo hacerlo.


Anterior: , Subir: Instalación del sistema   [Índice general][Índice]

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.


Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

4 Empezando

Es probable que haya llegado a esta sección o bien porque haya instalado Guix sobre otra distribución (véase Instalación), o bien porque haya instalado el sistema Guix completo (véase 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 (véase 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"'.

En efecto, ahora debe indicarle a su intérprete dónde se encuentran instalados emacs y otros programas. Pegar las dos lineas previas hará exactamente eso: $HOME/.guix-profile/bin—que es donde se encuentran instalados los paquetes—se añade a la variable de entorno PATH. Puede pegar estas dos líneas en su intérprete de modo que se hagan efectivas inmediatamente, pero aún más importante es añadirlas a ~/.bash_profile (o el archivo equivalente si no usa Bash) de modo que las variables de entorno adquieran ese valor la próxima vez que lance una sesión de su intérprete. Únicamente es necesario hacerlo una vez y otras variables de entorno con rutas de búsqueda se actualizarán de la misma manera—por ejemplo, si en algún momento instala python y bibliotecas en este lenguaje se definirá la variable PYTHONPATH.

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á: Véase 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, véase Desarrollo para herramientas adicionales. Y si simplemente tiene curiosidad, véase 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á: Véase Invocación de guix pull, para más información. Véase 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 (véase 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. Véase 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!


Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

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 (véase guix package, también puede usar la interfaz Emacs-Guix (véase 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

Siguiente: , Subir: Gestión de paquetes   [Índice general][Índice]

5.1 Características

Se asume que ya ha dado sus primeros pasos con Guix (véase 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 (véase 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 (véase 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 (véase 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 (véase 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 (véase 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 (véase 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 (véase Invocación de guix challenge).

El control sobre el entorno de construcción es una característica que también es útil para desarrolladoras. La orden guix environment permite a desarrolladoras de un paquete configurar rápidamente el entorno de desarrollo correcto para su paquete, sin tener que instalar manualmente las dependencias del paquete en su perfil (véase Invocación de guix environment).

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 (véase 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.


Siguiente: , Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

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 (véase 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 (véase --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 (véase Bash Startup Files en 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 (véase 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 (véase 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 (véase Módulos de paquetes).

A veces los paquetes tienen entradas propagadas: estas son las dependencias que se instalan automáticamente junto al paquete requerido (véase 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 (véase 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+))

Las desarrolladoras pueden encontrarlo útil para incluir un archivo guix.scm in la raíz del árbol de fuentes de su proyecto que puede ser usado para probar imágenes de desarrollo y crear entornos de desarrollo reproducibles (véase Invocación de guix environment).

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 (véase 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 (véase 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")))

En este ejemplo tenemos que conocer qué módulos definen las variables emacs y guile-2.0 para proporcionar la línea use-package-modules correcta, lo cual puede ser complicado. En cambio podemos proporcionar especificaciones regulares de paquetes y dejar a specifications->manifest buscar los objetos de paquete correspondientes así:

(specifications->manifest
 '("emacs" "guile@2.2" "guile@2.2:debug"))

Véase --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.

Por ejemplo, GCC necesita que las variables de entorno CPATH y LIBRARY_PATH estén definidas para poder buscar cabeceras y bibliotecas en el perfil de la usuaria (véase Environment Variables en Using the GNU Compiler Collection (GCC)). Si GCC y, digamos, la biblioteca de C están instaladas en el perfil, entonces --search-paths sugerirá fijar dichas variables a perfil/include y perfil/lib respectivamente.

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 (véase GNU recutils databases en 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 mesa10 (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

Véase Selection Expressions en 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 (véase GNU recutils databases en GNU recutils manual).

$ guix package --show=python | recsel -p name,version
name: python
version: 2.7.6

name: python
version: 3.3.5

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 python@3.4 | recsel -p name,version
name: python
version: 3.4.3
--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 (véase 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 (véase 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 (véase 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 (véase Canales).

Together with --export-manifest, this option provides information allowing you to replicate the current profile (véase 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 (véase 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 (véase Opciones comunes de construcción). It also supports package transformation options, such as --with-source, and preserves them across upgrades (véase Opciones de transformación de paquetes).


Siguiente: , Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

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 (véase 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.


Siguiente: , Subir: Sustituciones   [Índice general][Índice]

5.3.1 Servidor oficial de sustituciones.

El servidor ci.guix.gnu.org es una fachada a una granja de construcción oficial que construye paquetes de Guix continuamente para algunas arquitecturas, y los pone disponibles como sustituciones. Esta es la fuente predeterminada de sustituciones; puede ser forzada a cambiar pasando la opción --substitute-urls bien a guix-daemon (véase guix-daemon --substitute-urls) o bien a herramientas cliente como guix package (véase 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.

El uso de sustituciones de la granja de construcción oficial se realiza de manera predeterminada cuando se usa el sistema Guix (véase Distribución GNU). No obstante, no se realiza de manera predeterminada cuando se usa Guix en una distribución anfitriona, a menos que las active explícitamente via uno de los pasos recomendados de instalación (véase Instalación). Los siguientes párrafos describen como activar o desactivar las sustituciones para la granja oficial de construcción; el mismo procedimiento puede usarse para activar las sustituciones desde cualquier otro servidor que las proporcione.


Siguiente: , Anterior: , Subir: Sustituciones   [Índice general][Índice]

5.3.2 Autorización de servidores de sustituciones

Para permitir a Guix descargar sustituciones de ci.guix.gnu.org o un espejo suyo, debe añadir su clave pública a la lista de control de acceso (ACL) de las importaciones de archivos, mediante el uso de la orden guix archive (véase Invocación de guix archive). Hacerlo implica que confía que ci.guix.gnu.org no ha sido comprometido y proporciona sustituciones genuinas.

Nota: Si usa el sistema Guix puede saltarse esta sección: el sistema Guix autoriza las sustituciones desde ci.guix.gnu.org de manera predeterminada.

La clave pública para ci.guix.gnu.org se instala junto a Guix, en prefijo/share/guix/ci.guix.gnu.org.pub, donde prefijo es el prefij de instalación de Guix. Si ha instalado Guix desde las fuentes, debe asegurarse de que comprobó la firma GPG de guix-1.3.0.tar.gz, el cual contiene el archivo de clave pública. Una vez hecho, puede ejecutar algo así:

# guix archive --authorize < prefijo/share/guix/ci.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
…

El texto ha cambiado de “Se construirían las siguientes derivaciones” a “Se descargarían 112.3 MB”. Esto indica que las sustituciones de ci.guix.gnu.org son usables y serán descargadas, cuando sea posible, en construcciones futuras.

El mecanismo de sustituciones puede ser desactivado globalmente ejecutando guix-daemon con --no-subsitutes (véase 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.


Siguiente: , Anterior: , Subir: Sustituciones   [Índice general][Índice]

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 (véase modify-services).

Como ejemplo supongamos que desea obtener sustituciones desde guix.example.org y autorizar la clave de firma de dicho servidor, además del servidor ci.guix.gnu.org predeterminado. La configuración de sistema operativo resultante sería más o menos así:

(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 (véase guix-daemon --substitute-urls):
    … --substitute-urls='https://guix.example.org https://ci.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 (véase 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.

¡Ya lo tiene configurado! Las sustituciones se obtendrán a ser posible de https://guix.example.org, usando ci.guix.gnu.org en caso de fallo. Por supuesto puede enumerar tantos servidores de sustituciones como desee, teniendo en cuenta que el tiempo de búsqueda puede aumentar si se necesita contactar a muchos servidores.

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. Véase Verificación de sustituciones para entender este caso específico.


Siguiente: , Anterior: , Subir: Sustituciones   [Índice general][Índice]

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


Siguiente: , Anterior: , Subir: Sustituciones   [Índice general][Índice]

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.


Siguiente: , Anterior: , Subir: Sustituciones   [Índice general][Índice]

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 (véase 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 (véase Invocación de guix weather). Esta orden proporciona estadísticas de las sustituciones proporcionadas por un servidor.


Anterior: , Subir: Sustituciones   [Índice general][Índice]

5.3.7 Sobre la confianza en binarios

Hoy en día, el control individual sobre nuestra propia computación está a merced de instituciones, empresas y grupos con suficiente poder y determinación para subvertir la infraestructura de computación y explotar sus vulnerabilidades. Mientras que usar las sustituciones de ci.guix.gnu.org puede ser conveniente, recomendamos a las usuarias también construir sus paquetes, o incluso mantener su propia granja de construcción, de modo que ci.guix.gnu.org sea un objetivo menos interesante. Una manera de ayudar es publicando el software que construya usando guix publish de modo que otras tengan otro servidor más como opción para descargar sustituciones (véase Invocación de guix publish).

Guix tiene los cimientos para maximizar la reproducibilidad de las construcciones (véase 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 (véase 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 (véase 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.


Siguiente: , Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

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 (véase Invocación de guix size). guix graph también puede ser útil (véase 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 (véase 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 (véase Invocación de guix package).


Siguiente: , Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

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 (véase 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 (véase 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 (véase 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 (véase size specifications en 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 (véase --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.

Véase Invocación de guix size, para una herramienta que perfila el tamaño de la clausura de un elemento. Véase 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 (véase 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 (véase 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 (véase 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 (véase --disable-deduplication). Por tanto, esta opción es útil principalmente cuando el daemon se estaba ejecutando con --disable-deduplication.


Siguiente: , Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

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 (véase 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(véase 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

Generación 2	11 jun 2018 11:02:49
  guix e0cc7f6
    URL del repositorio: https://git.savannah.gnu.org/git/guix.git
    rama: origin/master
    revisión: e0cc7f669bec22c37481dd03a7941c7d11a64f1d
  2 paquetes nuevos: keepalived, libnfnetlink
  6 paquetes actualizados: emacs-nix-mode@2.0.4,
    guile2.0-guix@0.14.0-12.77a1aac, guix@0.14.0-12.77a1aac,
    heimdal@7.5.0, milkytracker@1.02.00, nix@2.0.4

Generación 3	13 jun 2018 23:31:07	(current)
  guix 844cc1c
    URL del repositorio: https://git.savannah.gnu.org/git/guix.git
    rama: origin/master
    revisión: 844cc1c8f394f03b404c5bb3aee086922373490c
  28 paquetes nuevos: emacs-helm-ls-git, emacs-helm-mu, …
  69 paquetes actualizados: borg@1.1.6, cheese@3.28.0, …

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 (véase 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 (véase 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”. Véase Canales, para más información.

--news
-N

Muestra la lista de paquetes añadidos o actualizados desde la última generación, así como, ocasionalmente, noticias escritas por las autoras del canal para las usuarias (véase Writing Channel News).

La información del paquete es la misma que la que se muestra cuando termina guix pull, pero sin la elipsis; es también similar a la salida de guix pull -l para la última generación (véase a continuación).

--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 (véase Invocación de guix package).

--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. Véase Canales, para más información.

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


Siguiente: , Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

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 (véase 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 (véase 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”. Véase 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 (véase Opciones comunes de construcción).


Siguiente: , Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

5.8 Inferiores

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

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

Técnicamente, un “inferior” es esencialmente un proceso Guix separado conectado con su Guix principal a través de una sesión interactiva (véase 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.

Cuando se combina con los canales (véase Canales), los inferiores proporcionan una forma simple de interactuar con una revisión separada de Guix. Por ejemplo, asumamos que desea instalar en su perfil el paquete guile actual, junto al paquete guile-json como existía en una revisión más antigua de Guix—quizá porque las versiones nuevas de guile-json tienen un API incompatible y quiere ejecutar su código contra la API antigua. Para hacerlo, puede escribir un manifiesto para usarlo con guix package --manifest (véase Invocación de guix package); en dicho manifiesto puede crear un inferior para esa versión antigua de Guix que le interesa, y buscará el paquete guile-json en el 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 (véase 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 (véase Expresiones-G). They are also transparently handled by the packages->manifest procedure, which is commonly used in manifests (véase 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.


Siguiente: , Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

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 (véase 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 (véase 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 (véase 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 (véase 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 (véase 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.


Anterior: , Subir: Gestión de paquetes   [Índice general][Índice]

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, véase 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 (véase 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 (véase 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 (véase 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 (véase gcry_pk_genkey en 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 (véase 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.

Por ejemplo, la siguiente orden extrae la sustitución de Emacs ofrecida por ci.guix.gnu.org en /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 (véase Invocación de guix challenge).

--list
-t

Lee un único elemento del archivo como es ofrecido por los servidores de sustituciones (véase 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

Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

6 Canales

Guix y su colección de paquetes se actualizan ejecutando guix pull (véase 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.


Siguiente: , Subir: Canales   [Índice general][Índice]

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 (véase cons and lists en 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.


Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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

De aquí en adelante, guix pull obtendrá el código de la rama super-hacks del repositorio en example.org. Las cuestiones relacionadas con la verificación se tratan más adelante (véase Verificación de canales).


Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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

La orden guix describe --format=channels puede incluso generar esta lista de canales directamente (véase Invocación de guix describe). El archivo resultante puede usarse con la opción -C de guix pull (véase Invocación de guix pull) o guix time-machine (véase 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. Véase Inferiores, para otro modo de tomar ventaja de estos superpoderes.


Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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!


Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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 (véase 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.


Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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 (véase 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 (véase Load Paths en 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 (véase Módulos en 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. Véase Verificación de canales, y Especificación de autorizaciones del canal, para obtener información sobre cómo hacerlo.


Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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

Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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.


Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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

La presentación de canales responde a estas preguntas describiendo la primera revisión de un canal que debe estar firmada. La primera vez que se obtiene un canal con guix pull o guix time-machine, la orden busca la revisión de la presentación y verifica que está firmada con la clave OpenPGP especificada. De ahí en adelante, verifica las revisiones de acuerdo con las reglas previas.

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 (véase 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. Véase 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.


Siguiente: , Anterior: , Subir: Canales   [Índice general][Índice]

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.


Anterior: , Subir: Canales   [Índice general][Índice]

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 entrada12 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 (véase Overview en 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 (véase xgettext Invocation en 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.


Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

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.

La orden guix environment proporciona una manera conveniente de configurar un entorno de desarrollo que contenga todas las dependencias y herramientas necesarias para trabajar en el paquete de software de su elección. La orden guix pack le permite crear aplicaciones empaquetadas que pueden ser distribuidas con facilidad a usuarias que no usen Guix.


Siguiente: , Subir: Desarrollo   [Índice general][Índice]

7.1 Invocación de guix environment

El propósito de guix environment es ayudar a las hackers en la creación de entornos de desarrollo reproducibles sin modificar los paquetes de su perfil. La herramienta guix environment toma uno o más paquetes, construye todas sus entradas y crea un entorno shell para usarlos.

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

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 (véase 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 (véase Bash Startup Files en 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

En otras situaciones, es más conveniente especificar una lista de paquetes necesarios en el entorno. Por ejemplo, la siguiente orden ejecuta python desde un entorno que contiene Python 2.7 y NumPy:

guix environment --ad-hoc python2-numpy python-2.7 -- python

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.

--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. Véase 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 (véase 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 `(("autoconf" ,autoconf-2.64)
                   ("automake" ,automake)
                   ("texinfo" ,texinfo)
                   ,@(package-native-inputs gdb))))
--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 (véase --manifest) y usa los mismos archivos de manifiesto.

--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 (véase 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.

--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;14 --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 (véase Opciones comunes de construcción) así como las opciones de transformación de paquetes (véase Opciones de transformación de paquetes).


Siguiente: , Anterior: , Subir: Desarrollo   [Índice general][Índice]

7.2 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, véase 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 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 (véase 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 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 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.

--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 veces15, 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 (véase --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 (véase --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.

--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" (véase GNU configuration triplets en 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 (véase 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 (véase El almacén) así como las raíces del recolector de basura (véase 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 (véase 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 (véase Opciones comunes de construcción) y todas las opciones de transformación de paquetes (véase Opciones de transformación de paquetes).


Siguiente: , Anterior: , Subir: Desarrollo   [Índice general][Índice]

7.3 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’ (véase Invoking guix package).


Anterior: , Subir: Desarrollo   [Índice general][Índice]

7.4 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 (véase 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” (véase 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 (véase formato de .guix-authorizations).


Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

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.


Siguiente: , Subir: Interfaz programática   [Índice general][Índice]

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 …)16 (véase Guile modules en 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> (véase 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)17. 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 (véase 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. Véase 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, véase Lanzamiento inicial.


Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

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 `(("gawk" ,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 (véase Scheme records en 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 (véase 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 (véase Módulos de paquetes).

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

Véase 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 (véase Invocación de guix build), pudiendo resolver cualquier fallo de construcción que encuentre (véase Depuración de fallos de construcción). Puede volver a la definición del paquete fácilmente usando la orden guix edit (véase Invocación de guix edit). Véase 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, véase 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 (véase 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 (véase El almacén).

Procedimiento Scheme: package-derivation almacén paquete [sistema]

Devuelve el objeto <derivation> del paquete pra el sistema (véase 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 (véase 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" (véase Specifying Target Triplets en Autoconf).

Una vez tenga sus definiciones de paquetes puede definir facilmente variantes de dichos paquetes. Véase Definición de variantes de paquetes para obtener más información sobre ello.


Siguiente: , Subir: Definición de paquetes   [Índice general][Índice]

8.2.1 Referencia de package

Esta sección resume todas las opciones disponibles en declaraciones package (véase 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

La versión del paquete, como una cadena.

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 (véase Referencia de origin). También puede ser cualquier otro objeto “tipo-archivo” como local-file, que denota un archivo del sistema local de archivos (véase local-file).

build-system

El sistema de construcción que debe ser usado para construir el paquete (véase 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: '())

Estos campos enumeran las dependencias del paquete. Cada uno es una lista de tuplas, donde cada tupla tiene una etiqueta para la entrada (una cadena) como su primer elemento, un paquete, origen o derivación como su segundo elemento, y opcionalmente el nombre de la salida que debe ser usada, cuyo valor predeterminado es "out" (véase Paquetes con múltiples salidas, para más información sobre salidas de paquetes). Por ejemplo, la lista siguiente especifica tres entradas:

`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;la salida "bin" de Glib

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 (véase 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 (véase el rol de los perfiles en Guix) junto al paquete al que pertenecen (véase 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. Véase Paquetes con múltiples salidas, para usos típicos de salidas adicionales.

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

Una lista de objetos search-path-specification describiendo las variables de entorno de rutas de búsqueda respetadas por el paquete.

replacement (predeterminado: 1.0)

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

synopsis

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

description

Una descripción más elaborada del paquete.

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

  ;; Cuando se compila de forma cruzada, Guile, por ejemplo
  ;; depende de una versión nativa de sí mismo. Añadirla aquí.
  (native-inputs (if (%current-target-system)
                     `(("self" ,this-package))
                     '())))

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

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.


Anterior: , Subir: Definición de paquetes   [Índice general][Índice]

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 (véase 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 (véase La mónada del almacén); most methods return a fixed-output derivation (véase 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 (véase Invocación de guix download) o guix hash (véase 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 (véase 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 (véase 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

Esta cadena indica o bien la revisión que se debe obtener (una cadena hexadecimal, o bien el hash SHA1 de la revisión o una cadena “corta” que la represente; esta última no está recomendada) o la etiqueta que se debe obtener.

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.


Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

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 (véase 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» (véase --manifest) y con su propia colleción de paquetes (véase 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 (véase 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)    ;para 'gdb'
             (srfi srfi-1))        ;para 'alist-delete'

(define gdb-sin-guile
  (package
    (inherit gdb)
    (inputs (alist-delete "guile"
                          (package-inputs gdb)))))

La llamada alist-delete anterior elimina la tupla del campo inputs cuyo primer elemento es "guile" (véase SRFI-1 Association Lists en GNU Guile Reference Manual).

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)
  ;; Devuelve un paquete luasocket construido con LUA.
  (package
    (name name)
    (version "3.0")
    ;; se omiten varios campos
    (inputs
     `(("lua" ,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. Véase Procedures en 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 (véase 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 (véase 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 (véase --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.


Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

8.4 Sistemas de construcción

Cada definición de paquete especifica un sistema de construcción y parámetros para dicho sistema de construcción (véase 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 (véase 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 (véase 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 (véase Definición de paquetes). Normalmente son parámetros con palabras clave (véase keyword arguments in Guile en 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 (véase 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 (véase configuration and makefile conventions en 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. Véase 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. Véase Fases de construcción, for more information.

#:configure-flags

This is a list of flags (strings) passed to the configure script. Véase 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 (véase --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 binaries, 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. Véase -rpath en 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 (véase 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 (véase 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.

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 (véase Compilation en 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 is read from the file Project.toml. This value can be overridden by passing the argument #:julia-package-name (which must be correctly capitalized).

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 (véase 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 Package.toml yet, will require this file to be created, too. The function julia-create-package-toml helps creating the file. You need to pass the outputs and the source of the package, it’s name (the same as the file-name parameter), the package uuid, the package version, and a list of dependencies specified by their name and their uuid.

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.

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

Para que instalan programas independientes Python bajo bin/, se encarga de envolver dichos programas de modo que su variable de entorno PYTHONPATH apunte a las bibliotecas Python de las que dependen.

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.

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 (véase Packages en 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.

Añade Meson y Ninja al conjunto de entradas, y pueden cambiarse con los parámetros #:meson y #:ninja en caso necesario. La versión de Meson predeterminada es meson-for-build, la cual es especial puesto que no limpia el RUNPATH de los binarios y bibliotecas durante la instalación.

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

Esta fase ejecuta ninja con el objetivo especificado en #:test-target, cuyo valor predeterminado es "test".

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

Esta fase se asegura de que todos los binarios pueden encontrar las bibliotecas que necesitan. Busca las bibliotecas necesarias en subdirectorios del paquete en construcción, y añade estas a RUNPATH en caso necesario. También elimina referencias a bibliotecas introducidas en la fase de construcción por meson-for-build, como las dependencias de las pruebas, que no se necesitan realmente para la ejecución del programa.

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 (véase build-expression->derivation).


Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

8.5 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 (véase 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:

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 (véase 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 (véase Invocación de guix-daemon).

Las fases de construcción se representan como listas asociativas o “alists” (véase Association Lists en 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ón18:

;; 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 (véase Pairs en 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 (véase Optional Arguments en 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 (véase 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 (véase configuration and makefile conventions en 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 (véase SRFI-1 Association Lists en GNU Guile Reference Manual); no obstante es más conveniente hacerlo con modify-phases (véase 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. Véase 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. Véase 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.


Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

8.6 Utilidades de construcción

En cuanto empiece a escribir definiciones de paquete no-triviales (véase Definición de paquetes) u otras acciones de construcción (véase 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) (véase 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 (véase Using Guile Modules en 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.6.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.6.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.6.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 (véase POSIX en 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 (véase Processes en 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] [#:keep-mtime? #f]

Copia el directorio fuente en destino. Sigue los enlaces simbólicos si follow-symlinks? es verdadero; en otro caso se preservan. Cuando keep-mtime? es verdadero se mantiene el tiempo de modificación de los archivos en fuente en aquellos copiados a destino. Muestra información detallada en el puerto log.

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* archivo
  (("hola")
   "buenos días\n")
  (("algo([a-z]+)otro(.*)$" todo letras fin)
   (string-append "cosa" letras fin)))

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

8.6.5 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 (véase Sistemas de construcción). Las fases de construcción se representan como listas asociativas o “alists” (véase Association Lists en GNU Guile Reference Manual) donde cada clave es un símbolo que nombra a la fase, y el valor asociado es un procedimiento (véase 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 (véase Optional Arguments en 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
    ;; Modificamos 'egrep' y 'fgrep' para que ejecuten 'grep' a
    ;; través de la ruta absoluta de su archivo en vez de buscar
    ;; dicho binario en la variable de entorno $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")))
        #t))))

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 hay guión 'configure'
  (replace 'install
    (lambda* (#:key outputs #:allow-other-keys)
      ;; El Makefile del paquete no tiene un objetivo
      ;; doesn't provide an "install", así que lo
      ;; hacemos a mano.
      (let ((bin (string-append (assoc-ref outputs "out")
                                "/bin")))
        (install-file "footswitch" bin)
        (install-file "scythe" bin)
        #t))))

Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

8.7 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 (véase 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 (véase Introducción).

Véase 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 (véase --listen).

ssh

These URIs allow you to connect to a remote daemon over SSH. This feature requires Guile-SSH (véase 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 (véase 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 1.3.0. Por favor, contacte con nosotras para compartir cualquier problema o sugerencias que pueda tener (véase 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 (véase La mónada del almacén).

Esta sección actualmente está incompleta.


Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

8.8 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 (véase 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 (véase 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 (véase 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 (véase 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, véase 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 => …>

Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

8.9 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 (véase 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 mproc19. 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 (véase Local Bindings en 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 (véase Definición de paquetes).


Siguiente: , Anterior: , Subir: Interfaz programática   [Índice general][Índice]

8.10 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 (véase 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 (véase 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 Scheme20: 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 (véase 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 (véase quasiquote en 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 vm)))
  (gexp->derivation "algo-con-maq-virtuales"
                    #~(begin
                        (use-modules (guix build utils)
                                     (gnu build vm))
                        )))

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 (véase 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 (véase 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 (véase 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 (véase 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 (véase 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 (véase Parameters en 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>.


Anterior: , Subir: Interfaz programática   [Índice general][Índice]

8.11 Invocación de guix repl

La orden guix repl lanza una sesión interactiva Guile (REPL) para la programación interactiva (véase Using Guile Interactively en 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 (véase 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.


Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

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.


Siguiente: , Subir: Utilidades   [Índice general][Índice]

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 (véase 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 | cut -f1,2 --output-delimiter=@)

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 (véase 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.


Siguiente: , Subir: Invocación de guix build   [Índice general][Índice]

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 (véase 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. Véase 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:// (véase 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 (véase 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 (véase 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 (véase 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 (véase Sustituciones).

--no-grafts

No “injerta” paquetes. En la práctica esto significa que las actualizaciones de paquetes disponibles como injertos no se aplican. Véase 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. Véase 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 (véase 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 (véase --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 (véase --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. Véase --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.


Siguiente: , Anterior: , Subir: Invocación de guix build   [Índice general][Índice]

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 (véase 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).

--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 (véase 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 (véase 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. Véase 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 (véase 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. Véase 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 (véase 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 (véase 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

Esta opción es similar a --with-branch, salvo que construye desde revisión en vez de usar la última revisión de la rama. revisión debe ser un identificador de revisión SHA1 de Git válido o una etiqueta.

--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 (véase Referencia de origin), which by default includes -p1 (véase patch Directories en 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 (véase 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 (véase 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 (véase 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? Véase Definición de variantes de paquetes para obtener una descripción de la interfaz programática disponible.


Siguiente: , Anterior: , Subir: Invocación de guix build   [Índice general][Índice]

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 (véase objetos “tipo-archivo”).

Como un ejemplo, archivo puede contener una definición como esta (véase 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 (véase --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 (véase Expresiones-G).

Por último, expr puede hacer referencia a un procedimiento mónadico sin parámetros (véase 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 (véase Definición de paquetes).

As with other derivations, the result of building a source derivation can be verified using the --check option (véase 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 (véase 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. Véase 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" (véase GNU configuration triplets en 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 (véase Sustituciones), o si el resultado de la construcción de un paquete es determinista. Véase 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. Véase 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!


Anterior: , Subir: Invocación de guix build   [Índice general][Índice]

9.1.4 Depuración de fallos de construcción

Cuando esté definiendo un paquete nuevo (véase 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 (véase --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. (véase 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 environment --no-grafts -C foo --ad-hoc strace gdb
[env]# source ./environment-variables
[env]# cd foo-1.2

Aquí, guix environment -C crea un contenedor y lanza un shell nuevo en él (véase Invocación de guix environment). El fragmento --ad-hoc strace gdb añade las ordenes strace y gdb al contenedor, las cuales pueden resultar útiles durante la depuración. La opción --no-grafts asegura que obtenemos exactamente el mismo entorno, con paquetes sin injertos (véase Actualizaciones de seguridad, para más información sobre los injertos).

Para acercarnos más al contenedor usado por el daemon de construcción, podemos eliminar /bin/sh:

[env]# rm /bin/sh

(No se preocupe, es inocuo: todo esto ocurre en el contenedor de usar y tirar creado por guix environment).

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.


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

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 (véase Construcción desde Git), o ha creado sus propios paquetes en GUIX_PACKAGE_PATH (véase 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.


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

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 (véase 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 (véase 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. Véase how to install the GnuTLS bindings for Guile en 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 (véase 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. Véase 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, véase 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.


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.4 Invocación de guix hash

La orden guix hash calcula el hash de un archivo. Es principalmente una conveniente herramienta para cualquiera que contribuya a la distribución: calcula el hash criptográfico de un archivo, que puede usarse en la definición de un paquete (véase Definición de paquetes).

La sintaxis general es:

guix hash opciones archivo

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.

algoritmo debe ser el nombre de un algoritmo criptográfico de hash implementado por Libgcrypt a través de Guile-Gcrypt—por ejemplo sha512 o sha3-256 (véase Hash Functions en 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

Calcula el hash de archivo recursivamente.

Es este caso el hash se calcula en un archivador que contiene archivo, incluyendo su contenido si es un directorio. Algunos de los metadatos de archivo son parte del archivador; por ejemplo, cuando archivo es un archivo normal, el hash es diferente dependiendo de si archivo es ejecutable o no. Los metadatos como las marcas de tiempo no influyen en el hash (véase Invocación de guix archive).

--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 (véase Referencia de origin):

$ git clone http://example.org/foo.git
$ cd foo
$ guix hash -rx .

Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

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 (véase 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. Véase --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.

La siguiente orden importa los metadatos para el paquete de Python itsdangerous:

guix import pypi itsdangerous
--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.

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

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

Importa metadatos desde CTAN, la completa red de archivos TeX para paquetes TeX que son parte de la distribución TeX Live.

La información del paquete se obtiene a través del API XML proporcionado por CTAN, mientras que el código fuente se descarga del repositorio SVN del proyecto TeX Live. Se hace porque CTAN no guarda archivos con versiones.

La siguiente orden importa los metadatos del paquete de TeX fontspec:

guix import texlive fontspec

Cuando se añade --archive=directorio, el código fuente no se descarga del subdirectorio latex del árbol texmf-dist/source en el repositorio SVN de Tex Live, sino de el directorio especificado bajo esa la misma raíz.

La siguiente orden importa los metadatos del paquete ifxetex de CTAN mientras que obtiene las fuentes del directorio texmf/source/generic:

guix import texlive --archive=generic ifxetex
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> (Véase 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) (véase Packages en 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 (véase ELPA package signatures en The GNU Emacs Manual).

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

Select the given repository (a repository name). Possible values include:

  • opam, the default opam repository,
  • coq or coq-released, the stable repository for coq packages,
  • coq-core-dev, the repository that contains development versions of coq,
  • coq-extra-dev, the repository that contains development versions of coq packages.
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.

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í (véase Contribuir).


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

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 (véase --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 (véase 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 (véase Ejecución de Guix antes de estar instalado):

$ ./pre-inst-env guix refresh -s non-core -u

Véase 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;

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.

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.

Véase 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 geiser@0.4 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 (véase kbxutil en 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

Véase --keyring en 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 (véase 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.


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.7 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 (véase 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 (véase 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. Véase 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 versiones21—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.

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 (véase Módulos de paquetes).

Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles a las herramientas de línea de órdenes.


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.8 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 (véase 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én22 consultando al daemon para determinar sus dependencias, y mide su tamaño en el almacén, de forma similar a du -ms --apparent-size (véase du invocation en GNU Coreutils).

Cuando los paquetes proporcionados no están en el almacén, guix size informa en base de las sustituciones disponibles (véase 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 (véase Invocación de guix graph).

Las opciones disponibles son:

--substitute-urls=urls

Usa la información de sustituciones de urls. Véase la misma opción en guix build.

--sort=clave

Ordena las líneas de acuerdo a clave, una de las siguientes opciones:

self

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 (véase Módulos de paquetes).

Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles a las herramientas de línea de órdenes.


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.9 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 (véase --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 (véase gnu-build-system).

Ahora bien, fíjese que las dependencias de estas entradas implícitas—es decir, las dependencias del lanzamiento inicial (véase 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 (véase 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 (véase 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 (véase 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 (véase 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

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 (véase 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 (véase 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!


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.10 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 (véase Sustituciones).

Cuando guix publish se ejecuta, lanza un servidor HTTP que permite a cualquiera que tenga acceso a través de la red obtener sustituciones de él. Esto significa que cualquier máquina que ejecute Guix puede actuar como si fuese una granja de construcción, ya que la interfaz HTTP es compatible con Cuirass, el software detrás de la granja de construcción ci.guix.gnu.org.

Por seguridad, cada sustitución se firma, permitiendo a las receptoras comprobar su autenticidad e integridad (véase 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 (véase 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 (véase 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

Una vez el servidor de publicación ha sido autorizado, el daemon puede descargar sustituciones de él. Véase 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 (véase 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 (véase 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, véase 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 (véase 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.

--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” (véase 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 (véase 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 (véase REPL Servers en 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 (véase guix-publish-service-type)

Si en vez de eso ejecuta Guix en una distribución distinta, siga estas instrucciones:


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.11 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 (véase Sustituciones), es importante haber verificado que proporciona los binarios correctos, y por tanto ponerlo a prueba23. 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. (véase 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"
actualizando sustituciones desde 'https://ci.guix.gnu.org'... 100.0%
actualizando sustituciones desde 'https://guix.example.org'... 100.0%
el contenido de /gnu/store/…-openssl-1.0.2d es diferente:
  hash local: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
  https://ci.guix.gnu.org/nar/…-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
  https://guix.example.org/nar/…-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim
  archivos diferentes:
    /lib/libcrypto.so.1.1
    /lib/libssl.so.1.1

el contenido de /gnu/store/…-git-2.5.0 es diferente:
  hash local: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha
  https://ci.guix.gnu.org/nar/…-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f
  https://guix.example.org/nar/…-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
  archivo diferente:
    /libexec/git-core/git-fsck

el contenido de /gnu/store/…-pius-2.1.1 es diferente:
  hash local: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
  https://ci.guix.gnu.org/nar/…-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
  https://guix.example.org/nar/…-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs
  archivo diferente:
    /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.

Como un ejemplo, guix.example.org siempre obtiene una respuesta diferente. Por otro modo, ci.guix.gnu.org coincide con las construcciones locales, excepto en el caso de Git. Esto puede indicar que el proceso de construcción de Git no es determinista, lo que significa que su salida varia en función de varias cosas que Guix no controla completamente, aunque la construcción de paquetes se realice en entornos aislados (véase Características). Las fuentes más comunes de indeterminismo incluyen la adición de marcas de tiempo en los resultados de la construcción, la inclusión de números aleatorios y las enumeraciones de directorios ordenadas por número de nodos-i. Véase https://reproducible-builds.org/docs/ para más información.

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 (véase 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

Esta orden muestra la diferencia entre los archivos resultantes de la construcción local y los archivos resultantes de la construcción en ci.guix.gnu.org (véase Comparing and Merging Files en Comparing and Merging Files). La orden diff funciona muy bien en archivos de texto. Cuando son binarios los archivos diferentes, una opción mejor es Diffoscope, una herramienta que ayuda en la visualización de diferencias en todo tipo de archivos.

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.

Si esta escribiendo paquetes para Guix, le recomendamos que compruebe si ci.guix.gnu.org y otros servidores de sustituciones obtienen el mismo resultado de construcción que el obtenido por usted:

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


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.12 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)24. 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. Véase 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 (véase Opciones comunes de construcción).


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.13 Invocación de guix container

Nota: En la versión 1.3.0, esta herramienta es experimental. La interfaz está sujeta a cambios radicales en el futuro.

El propósito de guix container es la manipulación de procesos en ejecución dentro de entornos aislados, normalmente conocido como un “contenedor”, típicamente creado por las órdenes guix environment (véase Invocación de guix environment) y guix system container (véase Invocación de guix system).

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.


Siguiente: , Anterior: , Subir: Utilidades   [Índice general][Índice]

9.14 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 (véase 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 (véase 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 (véase 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 -c 10
calculando 8.983 derivaciones de paquete para x86_64-linux...
buscando 9.343 elementos del almacén en https://ci.guix.gnu.org...
actualizando sustituciones desde 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  64,7% sustituciones disponibles (6.047 de 9.343)
…
Faltan 2502 paquetes de 'https://ci.guix.gnu.org' para 'x86_64-linux', entre los cuales:
    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.


Anterior: , Subir: Utilidades   [Índice general][Índice]

9.15 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 envueltos25. A continuación puede verse un ejemplo de la información que devuelve:

$ sudo guix processes
SessionPID: 19002
ClientPID: 19090
ClientCommand: guix environment --ad-hoc 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 (véase 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 (véase Selection Expressions en 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 (véase Record Sets en 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

Siguiente: , Anterior: , Subir: Top   [Índice general][Índice]

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 los servicios disponibles, la zona horaria y la configuración de localización, las cuentas de usuarias—se declaran en un lugar único. Dicha configuración del sistema puede ser instanciada—es decir, hecha efectiva.

Una de las ventajas de poner toda la configuración del sistema bajo el control de Guix es que permite actualizaciones transaccionales del sistema, y hace posible volver a una instanciación previa del sistema, en caso de que haya algún problema con la nueva (véase Características). Otra ventaja es que hace fácil replicar exactamente la misma configuración entre máquinas diferentes, o en diferentes momentos, sin tener que utilizar herramientas de administración adicionales sobre las propias herramientas del sistema.

Esta sección describe este mecanismo. Primero nos enfocaremos en el punto de vista de la administradora del sistema—explicando cómo se configura e instancia el sistema. Después mostraremos cómo puede extenderse este mecanismo, por ejemplo para añadir nuevos servicios del sistema.


Siguiente: , Subir: Configuración del sistema   [Índice general][Índice]

10.1 Uso de la configuración del sistema

El sistema operativo se configura proporcionando una declaración operating-system en un archivo que pueda ser proporcionado a la orden guix system (véase Invocación de guix system). Una configuración simple, con los servicios predeterminados del sistema, el núcleo Linux-Libre predeterminado, un disco de RAM inicial y un cargador de arranque puede ser como sigue:

;; This is an operating system configuration template
;; for a "bare bones" setup, with no X11 display server.

(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules screen ssh)

(operating-system
  (host-name "komputilo")
  (timezone "Europe/Berlin")
  (locale "en_US.utf8")

  ;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
  ;; target hard disk, and "my-root" is the label of the target
  ;; root file system.
  (bootloader (bootloader-configuration
                (bootloader grub-bootloader)
                (target "/dev/sdX")))
  (file-systems (cons (file-system
                        (device (file-system-label "my-root"))
                        (mount-point "/")
                        (type "ext4"))
                      %base-file-systems))

  ;; This is where user accounts are specified.  The "root"
  ;; account is implicit, and is initially created with the
  ;; empty password.
  (users (cons (user-account
                (name "alice")
                (comment "Bob's sister")
                (group "users")

                ;; Adding the account to the "wheel" group
                ;; makes it a sudoer.  Adding it to "audio"
                ;; and "video" allows the user to play sound
                ;; and access the webcam.
                (supplementary-groups '("wheel"
                                        "audio" "video")))
               %base-user-accounts))

  ;; Globally-installed packages.
  (packages (cons screen %base-packages))

  ;; Add services to the baseline: a DHCP client and
  ;; an SSH server.
  (services (append (list (service dhcp-client-service-type)
                          (service openssh-service-type
                                   (openssh-configuration
                                    (openssh openssh-sans-x)
                                    (port-number 2222))))
                    %base-services)))

Este ejemplo debería ser auto-descriptivo. Algunos de los campos definidos anteriormente, como host-name y bootloader, son necesarios. Otros como packages y services, pueden omitirse, en cuyo caso obtienen un valor por defecto.

Más adelante se muestran los efectos de algunos de los campos más importantes (véase Referencia de operating-system, para detalles acerca de todos los campos disponibles), y cómo instanciar el sistema operativo usando guix system.

Cargador de arranque

El campo bootloader describe el método que será usado para arrancar su sistema. Las máquinas basadas en procesadores Intel pueden arrancar en el “obsoleto” modo BIOS, como en el ejemplo previo. No obstante, máquinas más recientes usan la Interfaz Unificada Extensible de Firmware (UEFI) para arrancar. En ese caso, el capo bootloader debe contener algo parecido a esto:

(bootloader-configuration
  (bootloader grub-efi-bootloader)
  (target "/boot/efi"))

Véase Configuración del gestor de arranque, para más información sobre las opciones de configuración disponibles.

Paquetes visibles globalmente

El campo packages enumera los paquetes que serán visibles globalmente en el sistema, para todas las cuentas de usuaria—es decir, en la variable de entorno PATH de cada usuaria—sin tener en cuenta los perfiles de cada usuaria (véase Invocación de guix package). La variable %base-packages proporciona todas las herramientas esperadas para tareas básicas y de administración—incluyendo las utilidades básicas GNU, las herramientas de red GNU, el editor de texto ligero GNU Zile, find, grep, etc. El ejemplo previo se añade GNU Screen a estos, tomado del módulo (gnu packages screen) (véase Módulos de paquetes). La sintaxis (list package output) puede usarse para añadir una salida específica de un paquete:

(use-modules (gnu packages))
(use-modules (gnu packages dns))

(operating-system
  ;; ...
  (packages (cons (list bind "utils")
                  %base-packages)))

Referirse a los paquetes por nombre de variable, como antes a bind, tiene la ventaja de evitar ambigüedades; también permite que errores tipográficos y demás obtengan un diagnóstico directo como “variables sin definir”. La parte problemática es que se necesita conocer qué módulo define qué paquete, y aumentar adecuadamente la línea de use-package-modules. Para evitar esto, se puede usar el procedimiento specification->package del módulo (gnu packages), que devuelve el mejor paquete para un nombre dado, o nombre y versión:

(use-modules (gnu packages))

(operating-system
  ;; ...
  (packages (append (map specification->package
                         '("tcpdump" "htop" "gnupg@2.0"))
                    %base-packages)))

Servicios del sistema

El campo services enumera los servicios del sistema disponibles cuando el sistema arranque (véase Servicios). La declaración operating-system previa especifica que, además de los servicios básicos, queremos que el daemon de shell seguro OpenSSH espere conexiones por el puerto 2222 (véase openssh-service-type). En su implementación, openssh-service-type prepara todo para que sshd se inicie con las opciones de la línea de órdenes adecuadas, posiblemente generando bajo demanda los archivos de configuración necesarios (véase Definición de servicios).

De manera ocasional, en vez de usar los servicios básicos tal y como vienen, puede querer personalizarlos. Para hacerlo, use modify-services (véase modify-services) para modificar la lista.

Por ejemplo, supongamos que quiere modificar guix-daemon y Mingetty (el punto de acceso al sistema por consola) en la lista %base-services (véase %base-services). Para hacerlo, puede escribir lo siguiente en su declaración de sistema operativo:

(define %mis-servicios
  ;; Mi propia lista de servicios
  (modify-services %base-services
    (guix-service-type config =>
                       (guix-configuration
                        (inherit config)
                        ;; Obtenemos sustituciones desde example.org.
                        (substitute-urls
                          (list "https://example.org/guix"
                                "https://ci.guix.gnu.org"))))
    (mingetty-service-type config =>
                           (mingetty-configuration
                            (inherit config)
                            ;; Ingresamos automáticamente con
                            ;; la cuenta "guest".
                            (auto-login "guest")))))

(operating-system
  ;; …
  (services %mis-servicios))

Esto modifica la configuración—es decir, los parámetros de los servicios—de la instancia guix-service-type, y de todas las instancias de mingetty-service-type en la lista %base-services. Observe cómo se consigue: primero, enlazamos la configuración actual al identificador config en el cuerpo, y entonces escribimos el cuerpo de manera que evalúe a la configuración deseada. En particular, fíjese como se usa inherit para crear una nueva configuración que tiene los mismos valores que la configuración antigua, pero con unas pocas modificaciones.

La configuración para un uso típico de “escritorio”, con una partición de raíz cifrada, el servidor gráfico X11, GNOME y Xfce (las usuarias pueden escoger cual de estos entornos de escritorio usarán en la pantalla de inicio de sesión pulsando F1), gestión de red, gestión de energía y más, podría ser así:

;; This is an operating system configuration template
;; for a "desktop" setup with GNOME and Xfce where the
;; root partition is encrypted with LUKS.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop xorg)
(use-package-modules certs gnome)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")

  ;; Choose US English keyboard layout.  The "altgr-intl"
  ;; variant provides dead keys for accented characters.
  (keyboard-layout (keyboard-layout "us" "altgr-intl"))

  ;; Use the UEFI variant of GRUB with the EFI System
  ;; Partition mounted on /boot/efi.
  (bootloader (bootloader-configuration
                (bootloader grub-efi-bootloader)
                (target "/boot/efi")
                (keyboard-layout keyboard-layout)))

  ;; Specify a mapped device for the encrypted root partition.
  ;; The UUID is that returned by 'cryptsetup luksUUID'.
  (mapped-devices
   (list (mapped-device
          (source (uuid "12345678-1234-1234-1234-123456789abc"))
          (target "my-root")
          (type luks-device-mapping))))

  (file-systems (append
                 (list (file-system
                         (device (file-system-label "my-root"))
                         (mount-point "/")
                         (type "ext4")
                         (dependencies mapped-devices))
                       (file-system
                         (device (uuid "1234-ABCD" 'fat))
                         (mount-point "/boot/efi")
                         (type "vfat")))
                 %base-file-systems))

  ;; Create user `bob' with `alice' as its initial password.
  (users (cons (user-account
                (name "bob")
                (comment "Alice's brother")
                (password (crypt "alice" "$6$abc"))
                (group "users")
                (supplementary-groups '("wheel" "netdev"
                                        "audio" "video")))
               %base-user-accounts))

  ;; This is where we specify system-wide packages.
  (packages (append (list
                     ;; for HTTPS access
                     nss-certs
                     ;; for user mounts
                     gvfs)
                    %base-packages))

  ;; Add GNOME and Xfce---we can choose at the log-in screen
  ;; by clicking the gear.  Use the "desktop" services, which
  ;; include the X11 log-in service, networking with
  ;; NetworkManager, and more.
  (services (append (list (service gnome-desktop-service-type)
                          (service xfce-desktop-service-type)
                          (set-xorg-configuration
                           (xorg-configuration
                            (keyboard-layout keyboard-layout))))
                    %desktop-services))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

Un sistema gráfico con una selección de gestores de ventanas ligeros en vez de entornos de escritorio completos podría ser así:

;; This is an operating system configuration template
;; for a "desktop" setup without full-blown desktop
;; environments.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop)
(use-package-modules bootloaders certs emacs emacs-xyz ratpoison suckless wm
                     xorg)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")

  ;; Use the UEFI variant of GRUB with the EFI System
  ;; Partition mounted on /boot/efi.
  (bootloader (bootloader-configuration
                (bootloader grub-efi-bootloader)
                (target "/boot/efi")))

  ;; Assume the target root file system is labelled "my-root",
  ;; and the EFI System Partition has UUID 1234-ABCD.
  (file-systems (append
                 (list (file-system
                         (device (file-system-label "my-root"))
                         (mount-point "/")
                         (type "ext4"))
                       (file-system
                         (device (uuid "1234-ABCD" 'fat))
                         (mount-point "/boot/efi")
                         (type "vfat")))
                 %base-file-systems))

  (users (cons (user-account
                (name "alice")
                (comment "Bob's sister")
                (group "users")
                (supplementary-groups '("wheel" "netdev"
                                        "audio" "video")))
               %base-user-accounts))

  ;; Add a bunch of window managers; we can choose one at
  ;; the log-in screen with F1.
  (packages (append (list
                     ;; window managers
                     ratpoison i3-wm i3status dmenu
                     emacs emacs-exwm emacs-desktop-environment
                     ;; terminal emulator
                     xterm
                     ;; for HTTPS access
                     nss-certs)
                    %base-packages))

  ;; Use the "desktop" services, which include the X11
  ;; log-in service, networking with NetworkManager, and more.
  (services %desktop-services)

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

Este ejemplo se refiere al sistema de archivos /boot/efi por su UUID 1234-ABCD. Substituya este UUID con el UUID correcto en su sistema, como el devuelto por la orden blkid.

Véase Servicios de escritorio, para la lista exacta de servicios proporcionados por %desktop-services. Véase Certificados X.509, para información sobre el paquete nss-certs usado aquí.

De nuevo, %desktop-services es simplemente una lista de objetos de servicios. Si desea borrar servicios de aquí, puede hacerlo usando procedimientos de filtrado de listas (véase SRFI-1 Filtering and Partitioning en GNU Guile Reference Manual). Por ejemplo, la siguiente expresión devuelve una lista que contiene todos los servicios en %desktop-services excepto el servicio Avahi:

(remove (lambda (service)
          (eq? (service-kind service) avahi-service-type))
        %desktop-services)

Alternatively, the modify-services macro can be used:

(modify-services %desktop-services
  (delete avahi-service-type))

Instanciación del sistema

Asumiendo que la declaración de operating-system se encuentra en el archivo mi-configuración-del-sistema.scm, la orden guix system mi-conf-del-sistema.scm instancia esa configuración, y la convierte en la entrada predeterminada de GRUB en el arranque (véase Invocación de guix system).

La manera habitual de cambiar la configuración del sistema es actualizar este archivo y volver a ejecutar guix system reconfigure. Nunca se deberían tocar los archivos en /etc o ejecutar órdenes que modifiquen el estado del sistema como useradd o grub-install. De hecho, debe evitarlo ya que no únicamente anularía su garantía sino que también le impediría volver a una versión previa de su sistema, en caso de necesitarlo.

Hablando de vuelta atrás, cada vez que ejecuta guix system reconfigure se crea una nueva generación del sistema—sin modificar o borrar generaciones previas. Las generaciones previas tienen una entrada en el menú del cargador de arranque, lo que permite arrancarlas en caso de que algo funcionase mal en las últimas generaciones. Tranquilizador, ¿no? La orden guix system list-generations enumera las generaciones del sistema disponibles en el disco. Es también posible volver a una versión previa con las órdenes guix system roll-back y guix system switch-generation.

Aunque la orden guix system reconfigure no modificará las generaciones previas, debe tener cuidado cuando la generación actual no es la última (por ejemplo, después de invocar guix system roll-back), ya que la operación puede sobreescribir una generación posterior (véase Invocación de guix system).

La interfaz programática

A nivel Scheme, el grueso de una declaración operating-system se instancia con el siguiente procedimiento monádico (véase La mónada del almacén):

Procedimiento monádico: operating-system-derivation so

Devuelve una derivación que construye so, un objeto operating-system (véase Derivaciones).

La salida de la derivación es un único directorio que hace referencia a todos los paquetes, archivos de configuración y otros archivos auxiliares necesarios para instanciar so.

Este procedimiento se proporciona por el módulo (gnu system). Junto con (gnu services) (véase Servicios), este módulo contiene los entresijos del sistema Guix. ¡Asegúrese de echarle un vistazo!


Siguiente: , Anterior: , Subir: Configuración del sistema   [Índice general][Índice]

10.2 Referencia de operating-system

Esta sección resume todas las opciones disponibles en las declaraciones de operating-system (véase Uso de la configuración del sistema).

Tipo de datos: operating-system

Este es el tipo de datos que representa la configuración del sistema operativo. Con ello queremos decir toda la configuración global del sistema, no la configuración específica de las usuarias (véase Uso de la configuración del sistema).

kernel (predeterminado: linux-libre)

El objeto del paquete del núcleo del sistema operativo usado26.

hurd (predeterminado: #f)

El objeto del paquete de Hurd iniciado por el núcleo. Cuando se proporciona este campo, produce un sistema operativo GNU/Hurd. En ese caso, kernel también debe contener el paquete gnumach—el micronúcleo sobre el que se ejecuta Hurd.

Aviso: Esta característica es experimental y únicamente está implementada para imágenes de disco.

kernel-loadable-modules (predeterminados: '())

Una lista de objetos (habitualmente paquetes) desde los que se obtendrán los módulos del núcleo–por ejemplo (list ddcci-driver-linux).

kernel-arguments (predeterminados: %default-kernel-arguments)

Lista de cadenas o expresiones-G que representan parámetros adicionales a pasar en la línea de órdenes del núcleo—por ejemplo, ("console=ttyS0").

bootloader

El objeto de configuración del cargador de arranque del sistema. Véase Configuración del gestor de arranque.

label

Es una etiqueta (una cadena) con la que aparecerá en el menú del cargador de arranque. La etiqueta predeterminada incluye el nombre y la versión del núcleo.

keyboard-layout (predeterminada: #f)

This field specifies the keyboard layout to use in the console. It can be either #f, in which case the default keyboard layout is used (usually US English), or a <keyboard-layout> record. Véase Distribución de teclado, for more information.

Esta distribución de teclado se hace efectiva tan pronto el núcleo haya arrancado. Por ejemplo, la distribución de teclado está en efecto cuando introduzca una contraseña si su sistema de archivos raíz se encuentra en un dispositivo traducido luks-device-mapping (véase Dispositivos traducidos).

Nota: Esto no especifica la distribución de teclado usada por el cargador de arranque, ni tampoco la usada por el servidor gráfico. Véase Configuración del gestor de arranque, para información sobre cómo especificar la distribución de teclado del cargador de arranque. Véase Sistema X Window, para información sobre cómo especificar la distribución de teclado usada por el sistema de ventanas X.

initrd-modules (predeterminados: %base-initrd-modules)

La lista de módulos del núcleo Linux que deben estar disponibles en el disco inicial en RAM. Véase Disco en RAM inicial.

initrd (predeterminado: base-initrd)

Un procedimiento que devuelve un disco inicial en RAM para el núcleo Linux. Este campo se proporciona para permitir personalizaciones de bajo nivel y no debería ser necesario para un uso habitual. Véase Disco en RAM inicial.

firmware (predeterminado: %base-firmware)

Lista de paquetes de firmware que pueden ser cargados por el núcleo del sistema operativo.

El valor predeterminado incluye el firmware necesario para dispositivos WiFi basados en Atheros y Broadcom (módulos Linux-libre ath9k y b43-open, respectivamente). Véase Consideraciones sobre el hardware, para más información sobre hardware soportado.

host-name

El nombre de la máquina.

hosts-file

Un objeto tipo-archivo (véase objetos “tipo-archivo”) para ser usado como /etc/hosts (véase Host Names en The GNU C Library Reference Manual). El predeterminado es un archivo con entradas para localhost y host-name.

mapped-devices (predeterminados: '())

Una lista de dispositivos traducidos. Véase Dispositivos traducidos.

file-systems

Una lista de sistemas de archivos. Véase Sistemas de archivos.

swap-devices (predeterminados: '())

Lista de UUID, etiquetas de sistema de archivos o cadenas que identifiquen dispositivos o archivos que se usarán como espacio de intercambio (véase Memory Concepts en The GNU C Library Reference Manual). A continuación puede encontrar algunos ejemplos:

(list (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb"))

Use the swap partition with the given UUID. You can learn the UUID of a Linux swap partition by running swaplabel device, where device is the /dev file name of that partition.

(list (file-system-label "intercambio"))

Se usa la partición con etiqueta intercambio. De nuevo, la orden swaplabel le permite ver y cambiar la etiqueta de una partitición de intercambio de Linux.

(list "/archivo-de-intercambio")

Se usa el archivo /archivo-de-intercambio como espacio de intercambio.

(list "/dev/sda3" "/dev/sdb2")

Se usan las particiones /dev/sda3 y /dev/sdb2 como espacio de intercambio. Le recomendamos que haga referencia a los dispositivos de intercambio a través de UUID o etiquetas como se muestra en los ejemplos previos.

Es posible especificar un archivo de intercambio en un sistema de archivos en un dispositivo traducido (bajo /dev/mapper), siempre que la traducción y el sistema de archivos se especifiquen también. Véase Dispositivos traducidos y Sistemas de archivos.

users (predeterminadas: %base-user-accounts)
groups (predeterminados: %base-groups)

Lista de cuentas de usuaria y grupos. Véase Cuentas de usuaria.

Si la lista de usuarias carece de una cuenta de usuaria con UID 0, una cuenta “root” con UID 0 se añade automáticamente.

skeletons (predeterminados: (default-skeletons))

Una lista de tuplas de nombre de archivo de destino/objeto tipo-archivo (véase objetos “tipo-archivo”). Estos son los archivos de esqueleto que se añadirán al directorio de las cuentas de usuaria que se creen.

Por ejemplo, un valor válido puede parecer algo así:

`((".bashrc" ,(plain-file "bashrc" "echo Hola\n"))
  (".guile" ,(plain-file "guile"
                         "(use-modules (ice-9 readline))
                          (activate-readline)")))
issue (predeterminado: %default-issue)

Una cadena que denota el contenido del archivo /etc/issue, que se muestra cuando las usuarias ingresan al sistema en una consola de texto.

packages (predeterminados: %base-packages)

Una lista de paquetes instalados en el perfil global, que es accesible en /run/current-system/profile. Cada elemento debe ser una variable de paquete o una tupla paquete/salida. A continuación se muestra un ejemplo de ambos tipos:

(cons* git                     ; la salida predeterminada "out" 
       (list git "send-email") ; otra salida de git
       %base-packages)         ; el conjunto predeterminado

El conjunto predeterminado incluye utilidades básicas y es una buena práctica instalar utilidades no-básicas en los perfiles de las usuarias (véase Invocación de guix package).

timezone

Una cadena que identifica la zona horaria—por ejemplo, "Europe/Paris".

Puede ejecutar la orden tzselect para encontrar qué cadena de zona horaria corresponde con su región. Elegir una zona horaria no válida provoca un fallo en guix system.

locale (predeterminado: "en_US.utf8")

El nombre de la localización predeterminada (véase Locale Names en The GNU C Library Reference Manual). Véase Localizaciones, para más información.

locale-definitions (predeterminadas: %default-locale-definitions)

La lista de definiciones de localizaciones a compilar y que puede ser usada en tiempo de ejecución. Véase Localizaciones.

locale-libcs (predeterminadas: (list glibc))

La lista de paquetes GNU libc cuyos datos de localización y herramientas son usadas para las definiciones de localizaciones. Véase Localizaciones, para consideraciones de compatibilidad que justifican esta opción.

name-service-switch (predeterminado: %default-nss)

Configuración del selector de servicios de nombres de libc (NSS)—un objeto <name-service-switch>. Véase Selector de servicios de nombres, para detalles.

services (predeterminados: %base-services)

Una lista de objetos service denotando los servicios del sistema. Véase Servicios.

essential-services (predeterminados: ...)

La lista de “servicios esenciales”—es decir, cosas como instancias de system-service-type y host-name-service-type (véase Referencia de servicios), las cuales se derivan de su definición de sistema operativo en sí. Como usuaria nunca debería modificar este campo.

pam-services (predeterminados: (base-pam-services))

Servicios de los módulos de identificación conectables (PAM) de Linux.

setuid-programs (predeterminados: %setuid-programs)

Lista de expresiones-G con valores de cadena que denotan los programas setuid. Véase Programas con setuid.

sudoers-file (predeterminado: %sudoers-specification)

El contenido de /etc/sudoers como un objeto tipo-archivo (véase local-file y plain-file).

Este archivo especifica qué usuarias pueden usar la orden sudo, lo que se les permite hacer y qué privilegios pueden obtener. El comportamiento predefinido es que únicamente root y los miembros del grupo wheel pueden usar sudo.

Tipo de datos: this-operating-system

Cuando se usa en el ámbito léxico de un campo de una definición de sistema operativo, este identificador está enlazado al sistema operativo en definición.

El siguiente ejemplo muestra cómo hacer referencia al sistema operativo en definición en la definición del campo label:

(use-modules (gnu) (guix))

(operating-system
  ;; ...
  (label (package-full-name
          (operating-system-kernel this-operating-system))))

Es un error hacer referencia a this-operating-system fuera de una definición de sistema operativo.


Siguiente: , Anterior: , Subir: Configuración del sistema   [Índice general][Índice]

10.3 Sistemas de archivos

La lista de sistemas de archivos que deben montarse se especifica en el campo file-systems de la declaración del sistema operativo (véase Uso de la configuración del sistema). Cada sistema de archivos se declara usando la forma file-system, como en el siguiente ejemplo:

(file-system
  (mount-point "/home")
  (device "/dev/sda3")
  (type "ext4"))

Como es habitual, algunos de los campos son obligatorios—aquellos mostrados en el ejemplo previo—mientras que otros pueden omitirse. Se describen a continuación.

Tipo de datos: file-system

Objetos de este tipo representan los sistemas de archivos a montar. Contienen los siguientes campos:

type

Este campo es una cadena que especifica el tipo de sistema de archivos—por ejemplo, "ext4".

mount-point

Designa la ruta donde el sistema de archivos debe montarse.

device

Nombra la “fuente” del sistema de archivos. Puede ser una de estas tres opciones: una etiqueta de sistema de archivos, un UUID de sistema de archivos o el nombre de un nodo /dev. Las etiquetas y UUID ofrecen una forma de hacer referencia a sistemas de archivos sin codificar su nombre de dispositivo actual27.

Las etiquetas del sistema de archivos se crean mediante el uso del procedimiento file-system-label, los UUID se crean mediante el uso de uuid y los nodos /dev son simples cadenas. A continuación se proporciona un ejemplo de un sistema de archivos al que se hace referencia mediante su etiqueta, como es mostrada por la orden e2label:

(file-system
  (mount-point "/home")
  (type "ext4")
  (device (file-system-label "mi-home")))

Los UUID se convierten dede su representación en forma de cadena (como se muestra con la orden tune2fs -l) mediante el uso de la forma uuid28, como sigue:

(file-system
  (mount-point "/home")
  (type "ext4")
  (device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))

Cuando la fuente de un sistema de archivos es un dispositivo traducido (véase Dispositivos traducidos), su campo device debe hacer referencia al nombre del dispositivo traducido—por ejemplo, "/dev/mapper/particion-raiz". Esto es necesario para que el sistema sepa que el montaje del sistema de archivos depende del establecimiento de la traducción de dispositivos correspondiente.

flags (predeterminadas: '())

Es una lista de símbolos que indican opciones del montado. Las opciones reconocidas incluyen read-only29, bind-mount30, no-dev (prohibición del acceso a archivos especiales), no-suid (ignora los bits setuid y setgid), no-atime (no actualiza la marca de tiempo del acceso a archivos), strict-atime (actualiza la marca de tiempo del acceso a archivos), lazy-time (únicamente actualiza la marca de tiempo en la versión en memoria del nodo-i) y no-exec (no permite de la ejecución de programas). Véase Mount-Unmount-Remount en The GNU C Library Reference Manual, para más información sobre estas opciones.

options (predeterminadas: #f)

Es o bien #f, o bien una cadena que denota las opciones de montaje proporcionadas al controlador del sistema de archivos. Véase Mount-Unmount-Remount en The GNU C Library Reference Manual para obtener detalles, y ejecute man 8 mount para conocer las opciones de varios sistemas de archivos. Tenga en cuenta los procedimientos file-system-options->alist y alist->file-system-options de (gnu system file-systems) pueden usarse para convertir las opciones de sistema de archivos proporcionadas como una lista asociativa a su representación en cadena y viceversa.

mount? (predeterminado: #t)

Este valor indica si debe montarse el sistema de archivos automáticamente al iniciar el sistema. Cuando se establece como #f, el sistema de archivos tiene una entrada en /etc/fstab (el cual es leído por la orden mount) pero no se montará automáticamente.

needed-for-boot? (predeterminado: #f)

Este valor lógico indica si el sistema de archivos es necesario para el arranque. Si es verdadero, el sistema de archivos se monta al cargar el disco inicial en RAM (initrd). Este es siempre el caso, por ejemplo, para el sistema de archivos raíz.

check? (predeterminado: #t)

Este valor lógico indica si el sistema de archivos se debe comprobar en busca de errores antes de montarse.

create-mount-point? (predeterminado: #f)

Cuando es verdadero, el punto de montaje es creado si no existía previamente.

mount-may-fail? (predeterminado: #f)

Cuando tiene valor verdadero indica que el montaje de este sistema de archivos puede fallar pero no debe considerarse un error. Es útil en casos poco habituales; un ejemplo de esto es efivarfs, un sistema de archivos que únicamente puede montarse en sistemas EFI/UEFI.

dependencies (predeterminadas: '())

Una lista de objetos <file-system> o <mapped-device> que representan sistemas de archivos que deben montarse o dispositivos traducidos que se deben abrir antes (y desmontar o cerrar después) que el declarado.

Como ejemplo, considere la siguiente jerarquía de montajes: /sys/fs/cgroup es una dependencia de /sys/fs/cgroup/cpu y /sys/fs/cgroup/memory.

Otro ejemplo es un sistema de archivos que depende de un dispositivo traducido, por ejemplo una partición cifrada (véase Dispositivos traducidos).

Procedimiento Scheme: file-system-label str

Este procedimiento devuelve un objeto opaco de etiqueta del sistema de archivos a partir de str, una cadena:

(file-system-label "home")
 #<file-system-label "home">

Las etiquetas del sistema de archivos se usan para hacer referencia a los sistemas de archivos por etiqueta en vez de por nombre de dispositivo. Puede haber encontrado previamente ejemplos en el texto.

El módulo (gnu system file-systems) exporta las siguientes variables útiles.

Variable Scheme: %base-file-systems

Estos son los sistemas de archivos esenciales que se necesitan en sistemas normales, como %pseudo-terminal-file-system y %immutable-store (véase a continuación). Las declaraciones de sistemas operativos deben contener siempre estos al menos.

Variable Scheme: %pseudo-terminal-file-systems

El sistema de archivos que debe montarse como /dev/pts. Permite la creación de pseudoterminales a través de openpty y funciones similares (véase Pseudo-Terminals en The GNU C Library Reference Manual). Los pseudoterminales son usados por emuladores de terminales como xterm.

Variable Scheme: %shared-memory-file-system

Este sistema de archivos se monta como /dev/shm y se usa para permitir el uso de memoria compartida entre procesos (véase shm_open en The GNU C Library Reference Manual).

Variable Scheme: %immutable-store

Este sistema de archivos crea un montaje enlazado (“bind-mount”) de /gnu/store, permitiendo solo el acceso de lectura para todas las usuarias incluyendo a root. Esto previene modificaciones accidentales por software que se ejecuta como root o por las administradoras del sistema.

El daemon sí es capaz de escribir en el almacén: vuelve a montar /gnu/store en modo lectura-escritura en su propio “espacio de nombres”.

Variable Scheme: %binary-format-file-system

El sistema de archivos binfmt_misc, que permite que el manejo de tipos de archivos ejecutables arbitrarios se delegue al espacio de usuaria. Necesita la carga del módulo del núcleo binfmt.ko.

Variable Scheme: %fuse-control-file-system

El sistema de archivos fusectl, que permite a usuarias sin privilegios montar y desmontar sistemas de archivos de espacio de usuaria FUSE. Necesita la carga del módulo del núcleo fuse.ko.

El módulo (gnu system uuid) proporciona herramientas para tratar con “identificadores únicos” de sistemas de archivos (UUID).

Procedimiento Scheme: uuid str [tipo]

Devuelve un objeto opaco de UUID (identificador único) del tipo (un símbolo) procesando str (una cadena):

(uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")
 #<<uuid> type: dce bv: …>

(uuid "1234-ABCD" 'fat)
 #<<uuid> type: fat bv: …>

tipo puede ser dce, iso9660, fat, ntfs, o uno de sus sinónimos habitualmente usados para estos tipos.

Los UUID son otra forma de hacer referencia de forma inequívoca a sistemas de archivos en la configuración de sistema operativo. Puede haber encontrado previamente ejemplos en el texto.


Subir: Sistemas de archivos   [Índice general][Índice]

10.3.1 Sistema de archivos Btrfs

El sistema de archivos Btrfs tiene características especiales, como los subvolúmenes, que merecen una explicación más detallada. La siguiente sección intenta cubrir usos básicos así como usos complejos del sistema de archivos Btrfs con el sistema Guix.

Con el uso más simple se puede describir un sistema de archivos Btrfs puede describirse, por ejemplo, del siguiente modo:

(file-system
  (mount-point "/home")
  (type "btrfs")
  (device (file-system-label "mi-home")))

El ejemplo siguiente es más complejo, ya que usa un subvolumen de Btrfs, llamado rootfs. El sistema de archivos tiene la etiqueta mi-btrfs, y se encuentra en un dispositivo cifrado (de aquí la dependencia de mapped-devices):

(file-system
  (device (file-system-label "mi-btrfs"))
  (mount-point "/")
  (type "btrfs")
  (options "subvol=rootfs")
  (dependencies mapped-devices))

Algunos cargadores de arranque, por ejemplo GRUB, únicamente montan una partición Btrfs en su nivel superior durante los momentos iniciales del arranque, y dependen de que su configuración haga referencia a la ruta correcta del subvolumen dentro de dicho nivel superior. Los cargadores de arranque que operan de este modo producen habitualmente su configuración en un sistema en ejecución donde las particiones Btrfs ya se encuentran montadas y donde la información de subvolúmenes está disponible. Como un ejemplo, grub-mkconfig, la herramienta de generación de configuración que viene con GRUB, lee /proc/self/mountinfo para determinar la ruta desde el nivel superior de un subvolumen.

El sistema Guix produce una configuración para el cargador de arranque usando la configuración del sistema operativo como su única entrada; por lo tanto es necesario extraer la información del subvolumen en el que se encuentra /gnu/store (en caso de estar en alguno) de la configuración del sistema operativo. Para ilustrar esta situación mejor, considere un subvolumen que se llama ’rootfs’ el cual contiene el sistema de archivos raiz. En esta situación, el cargador de arranque GRUB únicamente vería el nivel superior de la partición de raíz de Btrfs, por ejemplo:

/                   (nivel superior)
├── rootfs          (directorio del subvolumen)
    ├── gnu         (directorio normal)
        ├── store   (directorio normal)
[...]

Por lo tanto, el nombre del subvolumen debe añadirse al inicio de la ruta al núcleo, los binarios de initrd y otros archivos a los que haga referencia la configuración de GRUB en /gnu/store, para que puedan encontrarse en los momentos iniciales del arranque.

El siguiente ejemplo muestra una jerarquía anidada de subvolúmenes y directorios:

/                   (nivel superior)
├── rootfs          (subvolumen)
    ├── gnu         (directorio normal)
        ├── store   (subvolumen)
[...]

Este escenario funcionaría sin montar el subvolumen ’store’. Montar ’rootfs’ es suficiente, puesto que el nombre del subvolumen corresponde con el punto de montaje deseado en la jerarquía del sistema de archivos. Alternativamente se puede hacer referencia el subvolumen ’store’ proporcionando tanto el valor /rootfs/gnu/store como el valor rootfs/gnu/store a la opción subvol.

Por último, un ejemplo más elaborado de subvolúmenes anidados:

/                           (nivel superior)
├── root-snapshots          (subvolumen)
    ├── root-current        (subvolumen)
        ├── guix-store      (subvolumen)
[...]

Aquí, el subvolumen ’guix-store’ no corresponde con el punto de montaje deseado, por lo que es necesario montarlo. El subvolumen debe ser especificado completamente proporcionando su nombre de archivo a la opción subvol. Para ilustrar este ejemplo, el subvolumen ’guix-store’ puede montarse en /gnu/store usando una declaración de sistema de archivos como la siguiente:

(file-system
  (device (file-system-label "mi-otro-btrfs"))
  (mount-point "/gnu/store")
  (type "btrfs")
  (options "subvol=root-snapshots/root-current/guix-store,\
compress-force=zstd,space_cache=v2"))

Siguiente: , Anterior: , Subir: Configuración del sistema   [Índice general][Índice]

10.4 Dispositivos traducidos

The Linux kernel has a notion of device mapping: a block device, such as a hard disk partition, can be mapped into another device, usually in /dev/mapper/, with additional processing over the data that flows through it31. A typical example is encryption device mapping: all writes to the mapped device are encrypted, and all reads are deciphered, transparently. Guix extends this notion by considering any device or set of devices that are transformed in some way to create a new device; for instance, RAID devices are obtained by assembling several other devices, such as hard disks or partitions, into a new one that behaves as one partition.

Los dispositivos traducidos se declaran mediante el uso de la forma mapped-device, definida a continuación; ejemplos más adelante.

Tipo de datos: mapped-device

Objetos de este tipo representan traducciones de dispositivo que se llevarán a cabo cuando el sistema arranque.

source

This is either a string specifying the name of the block device to be mapped, such as "/dev/sda3", or a list of such strings when several devices need to be assembled for creating a new one. In case of LVM this is a string specifying name of the volume group to be mapped.

target

This string specifies the name of the resulting mapped device. For kernel mappers such as encrypted devices of type luks-device-mapping, specifying "my-partition" leads to the creation of the "/dev/mapper/my-partition" device. For RAID devices of type raid-device-mapping, the full device name such as "/dev/md0" needs to be given. LVM logical volumes of type lvm-device-mapping need to be specified as "VGNAME-LVNAME".

targets

This list of strings specifies names of the resulting mapped devices in case there are several. The format is identical to target.

type

Debe ser un objeto mapped-device-kind, que especifica cómo source se traduce a target.

Variable Scheme: luks-device-mapping

Define el cifrado de bloques LUKS mediante el uso de la orden cryptsetup del paquete del mismo nombre. Depende del módulo dm-crypt del núcleo Linux.

Variable Scheme: raid-device-mapping

Define un dispositivo RAID, el cual se ensambla mediante el uso de la orden mdadm del paquete del mismo nombre. Requiere la carga del módulo del núcleo Linux para el nivel RAID apropiado, como raid456 para RAID-4, RAID-5 o RAID-6, o raid10 para RAID-10.

Scheme Variable: lvm-device-mapping

This defines one or more logical volumes for the Linux Logical Volume Manager (LVM). The volume group is activated by the vgchange command from the lvm2 package.

El siguiente ejemplo especifica una traducción de /dev/sda3 a /dev/mapper/home mediante el uso de LUKS—la configuración de claves unificada de Linux, un mecanismo estándar para cifrado de disco. El dispositivo /dev/mapper/home puede usarse entonces como el campo device de una declaración file-system (véase Sistemas de archivos).

(mapped-device
  (source "/dev/sda3")
  (target "home")
  (type luks-device-mapping))

De manera alternativa, para independizarse de la numeración de dispositivos, puede obtenerse el UUID LUKS (identificador único) del dispositivo fuente con una orden así:

cryptsetup luksUUID /dev/sda3

y usarlo como sigue:

(mapped-device
  (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44"))
  (target "home")
  (type luks-device-mapping))

También es deseable cifrar el espacio de intercambio, puesto que el espacio de intercambio puede contener información sensible. Una forma de conseguirlo es usar un archivo de intercambio en un sistema de archivos en un dispositivo traducido a través del cifrado LUKS. Véase Particionado del disco, para un ejemplo.

Un dispositivo RAID formado por las particiones /dev/sda1 y /dev/sdb1 puede declararse como se muestra a continuación:

(mapped-device
  (source (list "/dev/sda1" "/dev/sdb1"))
  (target "/dev/md0")
  (type raid-device-mapping))

El dispositivo /dev/md0 puede usarse entonces como el campo device de una declaración file-system (véase Sistemas de archivos). Fíjese que no necesita proporcionar el nivel RAID; se selecciona durante la creación inicial y formato del dispositivo RAID y después se determina automáticamente.

LVM logical volumes “alpha” and “beta” from volume group “vg0” can be declared as follows:

(mapped-device
  (source "vg0")
  (targets (list "vg0-alpha" "vg0-beta"))
  (type lvm-device-mapping))

Devices /dev/mapper/vg0-alpha and /dev/mapper/vg0-beta can then be used as the device of a file-system declaration (véase Sistemas de archivos).


Siguiente: , Anterior: , Subir: Configuración del sistema   [Índice general][Índice]

10.5 Cuentas de usuaria

Los grupos y cuentas de usuaria se gestionan completamente a través de la declaración operating-system. Se especifican con las formas user-account y user-group:

(user-account
  (name "alicia")
  (group "users")
  (supplementary-groups '("wheel"   ;permite usar sudo, etc.
                          "audio"   ;tarjeta de sonido
                          "video"   ;dispositivos audivisuales como cámaras
                          "cdrom")) ;el veterano CD-ROM
  (comment "hermana de Roberto"))

Esta es una cuenta que usa un shell diferente y un directorio personalizado (el predeterminado sería "/home/rober"):

(user-account
  (name "rober")
  (group "users")
  (comment "hermano de Alicia")
  (shell (file-append zsh "/bin/zsh"))
  (home-directory "/home/roberto"))

Durante el arranque o tras la finalización de guix system reconfigure, el sistema se asegura de que únicamente las cuentas de usuaria y grupos especificados en la declaración operating-system existen, y con las propiedades especificadas. Por tanto, la creación o modificación de cuentas o grupos realizadas directamente invocando órdenes como useradd se pierden al reconfigurar o reiniciar el sistema. Esto asegura que el sistema permanece exactamente como se declaró.

Tipo de datos: user-account

Objetos de este tipo representan cuentas de usuaria. Los siguientes miembros pueden ser especificados:

name

El nombre de la cuenta de usuaria.

group

Este es el nombre (una cadena) o identificador (un número) del grupo de usuarias al que esta cuenta pertenece.

supplementary-groups (predeterminados: '())

Opcionalmente, esto puede definirse como una lista de nombres de grupo a los que esta cuenta pertenece.

uid (predeterminado: #f)

Este es el ID de usuaria para esta cuenta (un número), o #f. En el último caso, un número es seleccionado automáticamente por el sistema cuando la cuenta es creada.

comment (predeterminado: "")

Un comentario sobre la cuenta, como el nombre completo de la propietaria.

home-directory

Este es el nombre del directorio de usuaria de la cuenta.

create-home-directory? (predeterminado: #t)

Indica si el directorio de usuaria de esta cuenta debe ser creado si no existe todavía.

shell (predeterminado: Bash)

Esto es una expresión-G denotando el nombre de archivo de un programa que será usado como shell (véase Expresiones-G). Por ejemplo, podría hacer referencia al ejecutable de Bash de este modo:

(file-append bash "/bin/bash")

... y al ejecutable de Zsh de este otro:

(file-append zsh "/bin/zsh")
system? (predeterminado: #f)

Este valor lógico indica si la cuenta es una cuenta “del sistema”. Las cuentas del sistema se tratan a veces de forma especial; por ejemplo, los gestores gráficos de inicio no las enumeran.

password (predeterminada: #f)

Normalmente debería dejar este campo a #f, inicializar la contraseña de usuaria como root con la orden passwd, y entonces dejar a las usuarias cambiarla con passwd. Las contraseñas establecidas con passwd son, por supuesto, preservadas entre reinicio y reinicio, y entre reconfiguraciones.

Si usted realmente quiere tener una contraseña prefijada para una cuenta, entonces este campo debe contener la contraseña cifrada, como una cadena. Puede usar el procedimiento crypt para este fin:

(user-account
  (name "carlos")
  (group "users")

  ;; Especifica una contraseña inicial mediante un hash SHA-512.
  (password (crypt "ContraseñaInicial!" "$6$abc")))

Nota: El hash de esta contraseña inicial estará disponible en un archivo en /gnu/store, legible por todas las usuarias, por lo que este método debe usarse con precaución.

Véase Passphrase Storage en The GNU C Library Reference Manual, para más información sobre el cifrado de contraseñas, y Encryption en GNU Guile Reference Manual, para información sobre el procedimiento de Guile crypt.

Las declaraciones de grupos incluso son más simples:

(user-group (name "estudiantes"))
Tipo de datos: user-group

Este tipo es para grupos de usuarias. Hay únicamente unos pocos campos:

name

El nombre del grupo.

id (predeterminado: #f)

El identificador del grupo (un número). Si es #f, un nuevo número es reservado automáticamente cuando se crea el grupo.

system? (predeterminado: #f)

Este valor booleano indica si el grupo es un grupo “del sistema”. Los grupos del sistema tienen identificadores numéricos bajos.

password (predeterminada: #f)

¿Qué? ¿Los grupos de usuarias pueden tener una contraseña? Bueno, aparentemente sí. A menos que sea #f, este campo especifica la contraseña del grupo.

Por conveniencia, una variable contiene una lista con todos los grupos de usuarias básicos que se puede esperar: