Next: La cadena de herramientas de GCC, Previous: Invocación de guix environment
, Up: Desarrollo [Contents][Index]
guix pack
De manera ocasional querrá dar software a gente que (¡todavía!) no tiene la
suerte de usar Guix. Usted les diría que ejecuten guix package -i
algo
, pero eso no es posible en este caso. Aquí es donde viene
guix pack
.
Nota: Si está buscando formas de intercambiar binarios entre máquinas que ya ejecutan Guix, see Invocación de
guix copy
, Invocación deguix publish
, y Invocación deguix archive
.
La orden guix pack
crea un paquete reducido o
empaquetado de software: crea un archivador tar u otro tipo que
contiene los binarios del software en el que está interesada y todas sus
dependencias. El archivo resultante puede ser usado en una máquina que no
tiene Guix, y la gente puede ejecutar exactamente los mismos binarios que
usted tiene con Guix. El paquete en sí es creado de forma reproducible
bit-a-bit, para que cualquiera pueda verificar que realmente contiene los
resultados de construcción que pretende distribuir.
Por ejemplo, para crear un empaquetado que contenga Guile, Emacs, Geiser y todas sus dependencias, puede ejecutar:
$ guix pack guile emacs emacs-geiser … /gnu/store/…-pack.tar.gz
El resultado aquí es un archivador tar que contiene un directorio de
/gnu/store con todos los paquetes relevantes. El archivador
resultante contiene un perfil con los tres paquetes de interés; el
perfil es el mismo que se hubiera creado por guix package -i
. Este
es el mecanismo usado para crear el propio archivador de binarios separado
de Guix (see Instalación binaria).
Las usuarias de este empaquetad tendrán que ejecutar /gnu/store/…-profile/bin/guile para ejecutar guile, lo que puede resultar inconveniente. Para evitarlo, puede crear, digamos, un enlace simbólico /opt/gnu/bin al perfil:
guix pack -S /opt/gnu/bin=bin guile emacs emacs-geiser
De este modo, las usuarias pueden escribir alegremente /opt/gnu/bin/guile y disfrutar.
¿Qué pasa se la receptora de su paquete no tiene privilegios de root en su máquina y por lo tanto no puede desempaquetarlo en la raíz del sistema de archivos? En ese caso, lo que usted desea es usar la opción --relocatable (véase a continuación). Esta opción produce binarios reposicionables, significando que pueden ser colocados en cualquier lugar de la jerarquía del sistema de archivos: en el ejemplo anterior, las usuarias pueden desempaquetar el archivador en su directorio de usuaria y ejecutar directamente ./opt/gnu/bin/guile.
De manera alternativa, puede producir un empaquetado en el formato de imagen Docker usando la siguiente orden:
guix pack -f docker -S /bin=bin guile guile-readline
El resultado es un archivador “tar” que puede ser proporcionado a la orden
docker load
, seguida de docker run
:
docker load < archivo docker run -ti guile-guile-readline /bin/guile
donde archivo es la imagen devuelta por guix pack, y
guile-guile-readline
es la “etiqueta de imagen”. Véase la
documentación de Docker para más información.
Otra opción más es producir una imagen SquashFS con la siguiente orden:
guix pack -f squashfs bash guile emacs emacs-geiser
El resultado es una imagen de sistema de archivos SquashFS que puede ser o
bien montada, o bien usada directamente como una imagen contenedora de
sistemas de archivos con el entorno de
ejecución de contenedores Singularity, usando órdenes como
singularity shell
o singularity exec
.
Varias opciones de la línea de órdenes le permiten personalizar su empaquetado:
--format=formato
-f formato
Produce un empaquetado en el formato específico.
Los formatos disponibles son:
tarball
Es el formato predeterminado. Produce un archivador que contiene todos los binarios y enlaces simbólicos especificados.
docker
Produce un archivador que sigue la
especificación de imágenes Docker. El “nombre de repositorio” como
aparece en la salida de la orden docker images
se calcula a partir
de los nombres de paquete proporcionados en la línea de órdenes o en el
archivo de manifiesto.
squashfs
Produce una imagen SquashFS que contiene todos los binarios y enlaces simbólicos especificados, así como puntos de montaje vacíos para sistemas de archivos virtuales como procfs.
Nota: Singularity necesita que proporcione /bin/sh en la imagen. Por esta razón,
guix pack -f squashfs
siempre implica-S /bin=bin
. Por tanto, su invocación deguix pack
debe siempre comenzar de manera similar a esta:guix pack -f squashfs bash …Si se olvida del paquete
bash
(o similar),singularity run
ysingularity exec
fallarán con el mensaje “no existe el archivo o directorio”, lo que no sirve de ayuda.
deb
This produces a Debian archive (a package with the ‘.deb’ file extension) containing all the specified binaries and symbolic links, that can be installed on top of any dpkg-based GNU(/Linux) distribution. Advanced options can be revealed via the --help-deb-format option. They allow embedding control files for more fine-grained control, such as activating specific triggers or providing a maintainer configure script to run arbitrary setup code upon installation.
guix pack -f deb -C xz -S /usr/bin/hello=bin/hello hello
Nota: Because archives produced with
guix pack
contain a collection of store items and because eachdpkg
package must not have conflicting files, in practice that means you likely won’t be able to install more than one such archive on a given system.
Aviso:
dpkg
will assume ownership of any files contained in the pack that it does not know about. It is unwise to install Guix-produced ‘.deb’ files on a system where /gnu/store is shared by other software, such as a Guix installation or other, non-deb packs.
--relocatable
-R
Produce binarios reposicionables—es decir, binarios que se pueden encontrar en cualquier lugar de la jerarquía del sistema de archivos, y ejecutarse desde allí.
Cuando se proporciona una vez la opción, los binarios resultantes necesitan la implementación de espacios de nombres de usuaria del núcleo Linux; cuando se proporciona dos veces20, los binarios reposicionables usan otras técnicas si los espacios de nombres de usuaria no están disponibles, y funcionan esencialmente en cualquier sitio—véase más adelante las implicaciones.
Por ejemplo, si crea un empaquetado que contiene Bash con:
guix pack -RR -S /mybin=bin bash
... puede copiar ese empaquetado a una máquina que no tiene Guix, y desde su directorio, como una usuaria normal, ejecutar:
tar xf pack.tar.gz ./mibin/sh
En ese shell, si escribe ls /gnu/store
, notará que /gnu/store
muestra y contiene todas las dependencias de bash
, ¡incluso cuando la
máquina no tiene el directorio /gnu/store! Esto es probablemente el
modo más simple de desplegar software construido en Guix en una máquina
no-Guix.
Nota: No obstante hay un punto a tener en cuenta: esta técnica descansa en la característica de espacios de nombres de usuaria del núcleo Linux, la cual permite a usuarias no privilegiadas montar o cambiar la raíz. Versiones antiguas de Linux no los implementan, y algunas distribuciones GNU/Linux los desactivan.
Para producir binarios reposicionables que funcionen incluso en ausencia de espacios de nombre de usuaria, proporcione --relocatable o -R dos veces. En ese caso, los binarios intentarán el uso de espacios de nombres de usuaria y usarán otro motor de ejecución si los espacios de nombres no están disponibles. Existe implementación para siguientes motores de ejecución:
default
Intenta usar espacios de nombres de usuaria y usa PRoot en caso de no estar disponibles (véase a continuación).
performance
Intenta usar espacios de nombres de usuaria y usa Fakechroot en caso de no estar disponibles (véase a continuación).
userns
Usa espacios de nombres de usuaria o aborta el programa si no están disponibles.
proot
Ejecución a través de PRoot. El programa PRoot proporciona el soporte necesario para la virtualización del sistema de archivos. Lo consigue mediante el uso de la llamada al sistema
ptrace
en el programa en ejecución. Esta aproximación tiene la ventaja de funcionar sin soporte especial en el núcleo, pero incurre en una sobrecarga en el tiempo de ejecución cada vez que se realiza una llamada al sistema.fakechroot
Ejecución a través de Fakechroot. Fakechroot virtualiza los accesos al sistema de archivos interceptando las llamadas a las funciones de la biblioteca de C como
open
,stat
,exec
, etcétera. Al contrario que PRoot, el proceso se somete únicamente a una pequeña sobrecarga. No obstante, no siempre funciona: algunos accesos realizados dentro de la biblioteca de C no se interceptan, ni tampoco los accesos al sistema de archivos a través de llamadas al sistema directas, lo que puede provocar un comportamiento impredecible.Cuando ejecute un programa recubierto puede solicitar explícitamente uno de los motores de ejecución enumerados previamente proporcionando el valor adecuado a la variable de entorno
GUIX_EXECUTION_ENGINE
.
--entry-point=orden
Usa orden como el punto de entrada del empaquetado resultante,
si el formato de empaquetado lo permite—actualmente docker
y
squashfs
(Singularity) lo permiten. orden debe ser una ruta
relativa al perfil contenido en el empaquetado.
El punto de entrada especifica la orden que herramientas como docker
run
o singularity run
arrancan de manera automática de forma
predeterminada. Por ejemplo, puede ejecutar:
guix pack -f docker --entry-point=bin/guile guile
El empaquetado resultante puede cargarse fácilmente y docker run
sin
parámetros adicionales lanzará bin/guile
:
docker load -i pack.tar.gz docker run image-id
--expression=expr
-e expr
Considera el paquete al que evalúa expr
Su propósito es idéntico a la opción del mismo nombre en guix
build
(see --expression en
guix build
).
--manifest=archivo
-m archivo
Usa los paquetes contenidos en el objeto manifest devuelto por el código Scheme en archivo. Esta opción puede repetirse varias veces, en cuyo caso los manifiestos se concatenan.
Esto tiene un propósito similar al de la opción del mismo nombre en
guix package
(see --manifest) y usa
los mismos archivos de manifiesto. Esto le permite definir una colección de
paquetes una vez y usarla tanto para crear perfiles como para crear archivos
en máquinas que no tienen instalado Guix. Fíjese que puede especificar
o bien un archivo de manifiesto o bien una lista de paquetes,
pero no ambas.
See Writing Manifests, for information on how to write a manifest.
See guix shell --export-manifest
, for
information on how to “convert” command-line options into a manifest.
--system=sistema
-s sistema
Intenta construir paquetes para sistema—por ejemplo,
x86_64-linux
—en vez del tipo de sistema de la máquina de
construcción.
--target=tripleta
¶Compilación cruzada para la tripleta, que debe ser una tripleta GNU
válida, cómo "aarch64-linux-gnu"
(see GNU configuration triplets in Autoconf).
--compression=herramienta
-C herramienta
Comprime el archivador resultante usando herramienta—un valor que
puede ser gzip
, zstd
, bzip2
, xz
, lzip
o
none
para no usar compresión.
--symlink=spec
-S spec
Añade los enlaces simbólicos especificados por spec al empaquetado. Esta opción puede aparecer varias veces.
La forma de spec es fuente=destino
, donde
fuente es el enlace simbólico que será creado y destino es el
destino del enlace simbólico.
Por ejemplo, -S /opt/gnu/bin=bin
crea un enlace simbólico
/opt/gnu/bin apuntando al subdirectorio bin del perfil.
--save-provenance
Almacena la información de procedencia para paquetes proporcionados en la línea de órdenes. La información de procedencia incluye la URL y revisión de los canales en uso (see Canales).
La información de procedencia se almacena en el archivo /gnu/store/…-profile/manifest dentro del empaquetado, junto a los metadatos habituales del paquete—el nombre y la versión de cada paquete, sus entradas propagadas, etcétera. Es información útil para la parte receptora del empaquetado, quien de ese modo conoce como se obtuvo (supuestamente) dicho empaquetado.
Esta opción no se usa de manera predeterminada debido a que, como las marcas de tiempo, la información de procedencia no aportan nada al proceso de construcción. En otras palabras, hay una infinidad de URL de canales e identificadores de revisiones que pueden llevar al mismo empaquetado. Almacenar estos metadatos “silenciosos” en la salida puede potencialmente romper la propiedad de reproducibilidad bit a bit entre fuentes y binarios.
--root=archivo
¶-r archivo
Hace que archivo sea un enlace simbólico al empaquetado resultante, y lo registra como una raíz del recolector de basura.
--localstatedir
--profile-name=nombre
Incluye el “directorio de estado local”, /var/guix, en el
empaquetado resultante, y notablemente el perfil
/var/guix/profiles/per-user/root/nombre—por defecto
nombre es guix-profile
, que corresponde con
~root/.guix-profile.
/var/guix contiene la base de datos del almacén (see El almacén)
así como las raíces del recolector de basura (see Invocación de guix gc
). Proporcionarlo junto al empaquetado significa que el almacén está
“completo” y Guix puede trabajar con él; no proporcionarlo significa que
el almacén está “muerto”: no se pueden añadir o borrar nuevos elementos
después de la extracción del empaquetado.
Un caso de uso para esto es el archivador tar autocontenido de binarios de Guix (see Instalación binaria).
--derivation
-d
Imprime el nombre de la derivación que construye el empaquetado.
--bootstrap
Usa los binarios del lanzamiento para construir el empaquetado. Esta opción es útil únicamente a las desarrolladoras de Guix.
Además, guix pack
acepta todas las opciones comunes de
construcción (see Opciones comunes de construcción) y todas las opciones de
transformación de paquetes (see Opciones de transformación de paquetes).
Este es un truco para
memorizarlo: -RR
, que añade PRoot, puede pensarse como “Realmente
Reposicionable”. Curioso, ¿no es cierto?
Next: La cadena de herramientas de GCC, Previous: Invocación de guix environment
, Up: Desarrollo [Contents][Index]