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]