---

10.1.2 Opciones de transformación de paquetes

Otro conjunto de opciones de línea de órdenes permitidas por guix build y también guix package son las opciones de transformación de paquetes. Son opciones que hacen posible la definición de variaciones de paquetes—por ejemplo, paquetes construidos con un código fuente diferente. Es una forma conveniente de crear paquetes personalizados al vuelo sin tener que escribir las definiciones de las variaciones del paquete (see Definición de paquetes).

Las opciones de transformación del paquete se preservan con las actualizaciones: guix upgrade intenta aplicar las opciones de transformación usadas inicialmente al crear el perfil para actualizar los paquetes.

Las opciones disponibles se enumeran a continuación. La mayor parte de las ordenes los aceptan, así como la opción --help-transform que enumera todas las opciones disponibles y una sinópsis (estas opciones no se muestran en la salida de --help por brevedad).

--tune[=cpu]

Use versions of the packages marked as “tunable” optimized for cpu. When cpu is native, or when it is omitted, tune for the CPU on which the guix command is running.

Valid cpu names are those recognized by the underlying compiler, by default the GNU Compiler Collection. On x86_64 processors, this includes CPU names such as nehalem, haswell, and skylake (see -march in Using the GNU Compiler Collection (GCC)).

As new generations of CPUs come out, they augment the standard instruction set architecture (ISA) with additional instructions, in particular instructions for single-instruction/multiple-data (SIMD) parallel processing. For example, while Core2 and Skylake CPUs both implement the x86_64 ISA, only the latter supports AVX2 SIMD instructions.

The primary gain one can expect from --tune is for programs that can make use of those SIMD capabilities and that do not already have a mechanism to select the right optimized code at run time. Packages that have the tunable? property set are considered tunable packages by the --tune option; a package definition with the property set looks like this:

(package
  (name "hello-simd")
  ;; ...

  ;; This package may benefit from SIMD extensions so
  ;; mark it as "tunable".
  (properties '((tunable? . #t))))

Other packages are not considered tunable. This allows Guix to use generic binaries in the cases where tuning for a specific CPU is unlikely to provide any gain.

Tuned packages are built with -march=CPU; under the hood, the -march option is passed to the actual wrapper by a compiler wrapper. Since the build machine may not be able to run code for the target CPU micro-architecture, the test suite is not run when building a tuned package.

To reduce rebuilds to the minimum, tuned packages are grafted onto packages that depend on them (see grafts). Thus, using --no-grafts cancels the effect of --tune.

We call this technique package multi-versioning: several variants of tunable packages may be built, one for each CPU variant. It is the coarse-grain counterpart of function multi-versioning as implemented by the GNU tool chain (see Function Multiversioning in Using the GNU Compiler Collection (GCC)).

--with-source=fuente

--with-source=paquete=fuente

--with-source=paquete@versión=fuente

Usa fuente como la fuente de paquete, y versión como su número de versión. fuente debe ser un nombre de archivo o una URL, como en guix download (see Invocación de guix download).

Cuando se omite paquete, se toma el nombre de paquete especificado en la línea de ordenes que coincide con el nombre base de fuente—por ejemplo, si fuente fuese /src/guile-2.0.10.tar.gz, el paquete correspondiente sería guile.

Del mismo modo, si se omite versión, la cadena de versión se deduce de đuente; en el ejemplo previo sería 2.0.10.

Esta opción permite a las usuarias probar versiones del paquete distintas a las proporcionadas en la distribución. El ejemplo siguiente descarga ed-1.7.tar.gz de un espejo GNU y lo usa como la fuente para el paquete ed:

guix build ed --with-source=mirror://gnu/ed/ed-1.4.tar.gz

As a developer, --with-source makes it easy to test release candidates, and even to test their impact on packages that depend on them:

guix build elogind --with-source=…/shepherd-0.9.0rc1.tar.gz 

… o la construcción desde una revisión en un entorno limpio:

$ git clone git://git.sv.gnu.org/guix.git
$ guix build guix --with-source=guix@1.0=./guix

--with-input=paquete=reemplazo

Substituye dependencias de paquete por dependencias de reemplazo. paquete debe ser un nombre de paquete, y reemplazo debe ser una especificación de paquete como guile o guile@1.8.

Por ejemplo, la orden siguiente construye Guix, pero substituye su dependencia de la versión estable actual de Guile con una dependencia en la versión antigua de Guile, guile@2.0:

guix build --with-input=guile=guile@2.0 guix

Esta sustitución se realiza de forma recursiva y en profundidad. Por lo que en este ejemplo, tanto guix como su dependencia guile-json (que también depende de guile) se reconstruyen contra guile@2.0.

Se implementa usando el procedimiento Scheme package-input-rewriting (see package-input-rewriting).

--with-graft=paquete=reemplazo

Es similar a --with-input pero con una diferencia importante: en vez de reconstruir la cadena de dependencias completa, reemplazo se construye y se injerta en los binarios que inicialmente hacían referencia a paquete. See Actualizaciones de seguridad, para más información sobre injertos.

Por ejemplo, la orden siguiente injerta la versión 3.5.4 de GnuTLS en Wget y todas sus dependencias, substituyendo las referencias a la versión de GnuTLS que tienen actualmente:

guix build --with-graft=gnutls=gnutls@3.5.4 wget

Esta opción tiene la ventaja de ser mucho más rápida que la reconstrucción de todo. Pero hay una trampa: funciona si y solo si paquete y reemplazo son estrictamente compatibles—por ejemplo, si proporcionan una biblioteca, la interfaz binaria de aplicación (ABI) de dichas bibliotecas debe ser compatible. Si reemplazo es incompatible de alguna manera con paquete, el paquete resultante puede no ser usable. ¡Úsela con precaución!

--with-debug-info=paquete

Construye paquete de modo que preserve su información de depuración y lo injerta en los paquetes que dependan de él. Es útil si paquete no proporciona ya información de depuración como una salida debug (see Instalación de archivos de depuración).

Por ejemplo, supongamos que está experimentando un fallo en Inkscape y querría ver qué pasa en GLib, una biblioteca con mucha profundidad en el grafo de dependencias de Inkscape. GLib no tiene una salida debug, de modo que su depuración es difícil. Afortunadamente puede reconstruir GLib con información de depuración e incorporarla a Inkscape:

guix install inkscape --with-debug-info=glib

Únicamente GLib necesita una reconstrucción por lo que esto tarda un tiempo razonable. See Instalación de archivos de depuración para obtener más información.

Nota: Esta opción funciona en su implementación interna proporcionando ‘#:strip-binaries? #f’ al sistema de construcción del paquete en cuestión (see Sistemas de construcción). La mayor parte de sistemas de construcción implementan dicha opción, pero algunos no lo hacen. En este caso caso se emite un error.

De igual modo, si se construye un paquete C/C++ sin la opción -g (lo que no es habitual que ocurra), la información de depuración seguirá sin estar disponible incluso cuando #:strip-binaries? sea falso.

--with-c-toolchain=paquete=cadena

Esta opción cambia la compilación de paquete y todo lo que dependa de él de modo que se constuya con cadena en vez de la cadena de herramientas de construcción para C/C++ de GNU predeterminada.

Considere este ejemplo:

guix build octave-cli \
  --with-c-toolchain=fftw=gcc-toolchain@10 \
  --with-c-toolchain=fftwf=gcc-toolchain@10

La orden anterior construye una variante de los paquetes fftw y fftwf usando la versión 10 de gcc-toolchain en vez de la cadena de herramientas de construcción predeterminada, y construye una variante de la interfaz de línea de órdenes GNU Octave que hace uso de ellos. El propio paquete de GNU Octave también se construye con gcc-toolchain@10.

Este otro ejemplo construye la biblioteca Hardware Locality (hwloc) y los paquetes que dependan de ella hasta intel-mpi-benchmarks con el compilador de C Clang:

guix build --with-c-toolchain=hwloc=clang-toolchain \
           intel-mpi-benchmarks

Nota: There can be application binary interface (ABI) incompatibilities among tool chains. This is particularly true of the C++ standard library and run-time support libraries such as that of OpenMP. By rebuilding all dependents with the same tool chain, --with-c-toolchain minimizes the risks of incompatibility but cannot entirely eliminate them. Choose package wisely.

--with-git-url=paquete=url ¶

Construye paquete desde la última revisión de la rama master del repositorio Git en url. Los submódulos del repositorio Git se obtienen de forma recursiva.

Por ejemplo, la siguiente orden construye la biblioteca NumPy de Python contra la última revisión de la rama master de Python en sí:

guix build python-numpy \
  --with-git-url=python=https://github.com/python/cpython

Esta opción también puede combinarse con --with-branch o --with-commit (véase más adelante).

Obviamente, ya que se usa la última revisión de la rama proporcionada, el resultado de dicha orden varia con el tiempo. No obstante es una forma conveniente de reconstruir una pila completa de software contra las últimas revisiones de uno o varios paquetes. Esto es particularmente útil en el contexto de integración continua (CI).

Los directorios de trabajo se conservan en caché en ~/.cache/guix/checkouts para agilizar accesos consecutivos al mismo repositorio. Puede desear limpiarla de vez en cuando para ahorrar espacio en el disco.

--with-branch=paquete=rama

Construye paquete desde la última revisión de rama. Si el campo source de paquete es un origen con el método git-fetch (see Referencia de origin) o un objeto git-checkout, la URL del repositorio se toma de dicho campo source. En otro caso, se debe especificar la URL del repositorio Git mediante el uso de --with-git-url.

Por ejemplo, la siguiente orden construye guile-sqlite3 desde la última revisión de su rama master y, una vez hecho, construye guix (que depende de él) y cuirass (que depende de guix) en base a esta construcción específica de guile-sqlite3:

guix build --with-branch=guile-sqlite3=master cuirass

--with-commit=paquete=revisión

This is similar to --with-branch, except that it builds from commit rather than the tip of a branch. commit must be a valid Git commit SHA1 identifier, a tag, or a git describe style identifier such as 1.0-3-gabc123.

--with-patch=package=file

Add file to the list of patches applied to package, where package is a spec such as python@3.8 or glibc. file must contain a patch; it is applied with the flags specified in the origin of package (see Referencia de origin), which by default includes -p1 (see patch Directories in Comparing and Merging Files).

As an example, the command below rebuilds Coreutils with the GNU C Library (glibc) patched with the given patch:

guix build coreutils --with-patch=glibc=./glibc-frob.patch

In this example, glibc itself as well as everything that leads to Coreutils in the dependency graph is rebuilt.

--with-latest=package

So you like living on the bleeding edge? This option is for you! It replaces occurrences of package in the dependency graph with its latest upstream version, as reported by guix refresh (see Invocación de guix refresh).

It does so by determining the latest upstream release of package (if possible), downloading it, and authenticating it if it comes with an OpenPGP signature.

As an example, the command below builds Guix against the latest version of Guile-JSON:

guix build guix --with-latest=guile-json

There are limitations. First, in cases where the tool cannot or does not know how to authenticate source code, you are at risk of running malicious code; a warning is emitted in this case. Second, this option simply changes the source used in the existing package definitions, which is not always sufficient: there might be additional dependencies that need to be added, patches to apply, and more generally the quality assurance work that Guix developers normally do will be missing.

You’ve been warned! In all the other cases, it’s a snappy way to stay on top. We encourage you to submit patches updating the actual package definitions once you have successfully tested an upgrade (see Contribuir).

--without-tests=paquete

Construye paquete sin ejecutar su batería de pruebas. Puede ser útil en situaciones en las que quiera omitir una larga batería de pruebas de un paquete intermedio, o si la batería de pruebas no falla de manera determinista. Debe usarse con cuidado, puesto que la ejecución de la batería de pruebas es una buena forma de asegurarse de que el paquete funciona como se espera.

La desactivación de las pruebas conduce a diferentes elementos en el almacén. Por tanto, cuando use esta opción, cualquier objeto que dependa de paquete debe ser reconstruido, como en este ejemplo:

guix install --without-tests=python python-notebook

La orden anterior instala python-notebook sobre un paquete python construido sin ejecutar su batería de pruebas. Para hacerlo, también reconstruye todos los paquetes que dependen de python, incluyendo el propio pyhton-notebook.

De manera interna, --without-tests depende del cambio de la opción #:tests? de la fase check del paquete (see Sistemas de construcción). Tenga en cuenta que algunos paquetes usan una fase check personalizada que no respeta el valor de configuración #:tests? #f. Por tanto, --without-tests no tiene ningún efecto en dichos paquetes.

¿Se pregunta cómo conseguir el mismo efecto usando código Scheme, por ejemplo en su manifiesto, o cómo escribir su propia transformación de paquetes? See Definición de variantes de paquetes para obtener una descripción de la interfaz programática disponible.