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


Notas al pie

(15)

Este es un truco para memorizarlo: -RR, que añade PRoot, puede pensarse como “Realmente Reposicionable”. Curioso, ¿no es cierto?


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