---

8.2.1 Referencia de package

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

The version of the package, as a string. See Versiones numéricas, for guidelines.

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

build-system

El sistema de construcción que debe ser usado para construir el paquete (see Sistemas de construcción).

arguments (predeterminados: '())

The arguments that should be passed to the build system (see Sistemas de construcción). This is a list, typically containing sequential keyword-value pairs, as in this example:

(package
  (name "example")
  ;; several fields omitted
  (arguments
    (list #:tests? #f                     ;skip tests
          #:make-flags #~'("VERBOSE=1")   ;pass flags to 'make'
          #:configure-flags #~'("--enable-frobbing"))))

The exact set of supported keywords depends on the build system (see Sistemas de construcción), but you will find that almost all of them honor #:configure-flags, #:make-flags, #:tests?, and #:phases. The #:phases keyword in particular lets you modify the set of build phases for your package (see Fases de construcción).

The REPL has dedicated commands to interactively inspect values of some of these arguments, as a convenient debugging aid (see Using Guix Interactively).

Compatibility Note: Until version 1.3.0, the arguments field would typically use quote (') or quasiquote (`) and no G-expressions, like so:

(package
  ;; several fields omitted
  (arguments   ;old-style quoted arguments
   '(#:tests? #f
     #:configure-flags '("--enable-frobbing"))))

To convert from that style to the one shown above, you can run guix style -S arguments package (see Invoking guix style).

inputs (predeterminadas: '()) ¶

native-inputs (predeterminadas: '())

propagated-inputs (predeterminadas: '())

These fields list dependencies of the package. Each element of these lists is either a package, origin, or other “file-like object” (see Expresiones-G); to specify the output of that file-like object that should be used, pass a two-element list where the second element is the output (see Paquetes con múltiples salidas, for more on package outputs). For example, the list below specifies three inputs:

(list libffi libunistring
      `(,glib "bin"))      ;the "bin" output of GLib

In the example above, the "out" output of libffi and libunistring is used.

Compatibility Note: Until version 1.3.0, input lists were a list of tuples, where each tuple has a label for the input (a string) as its first element, a package, origin, or derivation as its second element, and optionally the name of the output thereof that should be used, which defaults to "out". For example, the list below is equivalent to the one above, but using the old input style:

;; Old input style (deprecated).
`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;the "bin" output of GLib

This style is now deprecated; it is still supported but support will be removed in a future version. It should not be used for new package definitions. See Invoking guix style, on how to migrate to the new style.

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

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

search-paths (predeterminadas: '())

A list of search-path-specification objects describing search-path environment variables honored by the package. See Search Paths, for more on search path specifications.

As for inputs, the distinction between native-search-paths and search-paths only matters when cross-compiling. In a cross-compilation context, native-search-paths applies exclusively to native inputs whereas search-paths applies only to host inputs.

Packages such as cross-compilers care about target inputs—for instance, our (modified) GCC cross-compiler has CROSS_C_INCLUDE_PATH in search-paths, which allows it to pick .h files for the target system and not those of native inputs. For the majority of packages though, only native-search-paths makes sense.

replacement (predeterminado: 1.0)

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

synopsis

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

description

A more elaborate description of the package, as a string in Texinfo syntax.

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.

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

  ;; When cross-compiled, Guile, for example, depends on
  ;; a native version of itself.  Add it here.
  (native-inputs (if (%current-target-system)
                     (list this-package)
                     '())))

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

The following helper procedures are provided to help deal with package inputs.

Procedure: lookup-package-input package name

Procedure: lookup-package-native-input package name

Procedure: lookup-package-propagated-input package name

Procedure: lookup-package-direct-input package name

Look up name among package’s inputs (or native, propagated, or direct inputs). Return it if found, #f otherwise.

name is the name of a package depended on. Here’s how you might use it:

(use-modules (guix packages) (gnu packages base))

(lookup-package-direct-input coreutils "gmp")
⇒ #<package gmp@6.2.1 …>

In this example we obtain the gmp package that is among the direct inputs of coreutils.

Sometimes you will want to obtain the list of inputs needed to develop a package—all the inputs that are visible when the package is compiled. This is what the package-development-inputs procedure returns.

Procedure: package-development-inputs package [system] [#:target #f]

Return the list of inputs required by package for development purposes on system. When target is true, return the inputs needed to cross-compile package from system to target, where target is a triplet such as "aarch64-linux-gnu".

Note that the result includes both explicit inputs and implicit inputs—inputs automatically added by the build system (see Sistemas de construcción). Let us take the hello package to illustrate that:

(use-modules (gnu packages base) (guix packages))

hello
⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790>

(package-direct-inputs hello)
⇒ ()

(package-development-inputs hello)
⇒ (("source" …) ("tar" #<package tar@1.32 …>) …)

In this example, package-direct-inputs returns the empty list, because hello has zero explicit dependencies. Conversely, package-development-inputs includes inputs implicitly added by gnu-build-system that are required to build hello: tar, gzip, GCC, libc, Bash, and more. To visualize it, guix graph hello would show you explicit inputs, whereas guix graph -t bag hello would include implicit inputs (see Invocación de guix graph).

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