---

8.2.1 Référence de package

Cette section résume toutes les options disponibles dans les déclarations package (voir Définition des paquets).

Type de données :package

C’est le type de donnée représentant une recette de paquets.

name

Le nom du paquet, comme une chaîne de caractères.

version

La version du paquet, comme une chaine de caractères. Voir Numéros de version, pour un guide.

source

Un objet qui indique comment le code source du paquet devrait être récupéré. La plupart du temps, c’est un objet origin qui indique un fichier récupéré depuis internet (voir Référence de origin). Il peut aussi s’agir de tout autre objet « simili-fichier » comme un local-file qui indique un fichier du système de fichier local (voir local-file).

build-system

Le système de construction qui devrait être utilisé pour construire le paquet (voir Systèmes de construction).

arguments (par défaut : '())

Les arguments à passer au système de construction (voir Systèmes de construction). C’est une liste qui contient typiquement une séquence de paires de clefs-valeurs, comme dans cet exemple :

(package
  (name "exemple")
  ;; plusieurs champs omis
  (arguments
    (list #:tests? #f                     ;passer les tests
          #:make-flags #~'("VERBOSE=1")   ;passer les arguments à « make »
          #:configure-flags #~'("--enable-frobbing"))))

L’ensemble exact des mots-clés pris en charge dépend du système de construction (voir Systèmes de construction), mais vous trouverez qu’ils prennent presque tous en compte #:configure-flags, #:make-flags, #:tests? et #:phases. Le mot-clé #:phases en particulier vous permet de modifier l’ensemble des phases de construction pour votre paquet (voir Phases de construction).

The REPL has dedicated commands to interactively inspect values of some of these arguments, as a convenient debugging aid (voir Utiliser Guix de manière interactive).

Notes de compatibilité : 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 (voir Invoquer guix style).

inputs (par défaut : '()) ¶

native-inputs (par défaut : '())

propagated-inputs (par défaut : '())

Ces champs listent les dépendances du paquet. Chacune de ces listes est soit un paquet, une origine ou un autre « objet simili-fichier » (voir G-Expressions) ; pour spécifier la sortie de cet objet simili-fichier à utiliser, passez une liste à deux éléments où le second élément est la sortie (voir Des paquets avec plusieurs résultats, pour plus d’informations sur les sorties des paquets). Par exemple, la liste suivante spécifie trois entrées :

(list libffi libunistring
      `(,glib "bin"))      ;la sortie « bin » de GLib

Dans l’exemple au-dessus, on utilise la sortie "out" de libffi et de libunistring.

Notes de compatibilité : Jusqu’à la version 1.3.0, les listes d’entrées étaient des listes de tuples, où chaque tuple a une étiquette pour une entrée (une chaîne de caractères) comme premier élément, un paquet, une origine ou une dérivation comme deuxième élément et éventuellement le nom d’une sortie à utiliser qui est "out" par défaut. Par exemple, la liste ci-dessous est équivalente à celle au-dessus, mais utilise l’ancien style d’entrées :

;; Ancien style d'entrées (obsolète)
`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;la sortie "bin" de Glib

Ce style est maintenant obsolète ; il est toujours pris en charge mais la prise en charge sera supprimée dans une future version. Vous ne devriez pas l’utiliser pour de nouvelles définitions de paquets. Voir Invoquer guix style, pour apprendre à migrer vers le nouveau style.

La distinction entre native-inputs et inputs est nécessaire lorsqu’on considère la compilation croisée. Lors d’une compilation croisée, les dépendances listées dans inputs sont construites pour l’architecture cible ; inversement, les dépendances listées dans native-inputs sont construites pour l’architecture de la machine de construction.

native-inputs est typiquement utilisé pour lister les outils requis à la construction mais pas à l’exécution, comme Autoconf, Automake, pkg-config, Gettext ou Bison. guix lint peut rapporter des erreurs de ce type (voir Invoquer guix lint).

Enfin, propagated-inputs est similaire à inputs, mais les paquets spécifiés seront automatiquement installés sur les profils (voir le rôle des profils dans Guix) à côté du paquet auquel ils appartiennent (voir guix package, pour savoir comment guix package traite les entrées propagées).

Par exemple, cela est nécessaire lors de l’empaquetage d’une bibliothèque C/C++ qui a besoin des en-têtes d’une autre bibliothèque pour se compiler, ou lorsqu’un fichier pkg-config fait référence à un autre via son champ Requires.

Un autre exemple où le propagated-inputs est utile, c’est pour les langues qui ne disposent pas de la possibilité d’enregistrer le chemin de recherche à l’exécution comme le RUNPATH des fichiers ELF ; cela inclut Guile, Python, Perl, et plus encore. Lors de l’empaquetage de bibliothèques écrites dans ces langages, assurez-vous qu’elles peuvent trouver le code de bibliothèque dont elles dépendent au moment de l’exécution en listant les dépendances d’exécution dans propagated-inputs plutôt que inputs.

outputs (par défaut : '("out"))

La liste des noms de sorties du paquet. Voir Des paquets avec plusieurs résultats, pour des exemples typiques d’utilisation de sorties supplémentaires.

native-search-paths (par défaut : '())

search-paths (par défaut : '())

Une liste d’objets search-path-specification décrivant les variables d’environnement de recherche de chemins que ce paquet prend en compte. Voir Chemins de recherche, pour plus de détails sur les spécifications de chemins de recherche.

Comme pour les entrées, la distinction entre native-search-paths et search-paths n’est importante que pour la compilation croisée. Lors d’une compilation croisée, native-search-paths ne s’applique qu’aux entrées natives alors que search-paths ne s’applique qu’aux entrées hôtes.

Les paquets comme les compilateurs croisées font attention aux entrées de la cible — par exemple notre compilateur GCC croisé (modifié) a CROSS_C_INCLUDE_PATH dans search-paths, ce qui lui permet de trouver les fichiers .h du système cible et pas ceux des entrées natives. Pour la plupart des paquets cependant, seul native-search-paths a du sens.

replacement (par défaut : #f)

Ce champ doit être soit #f soit un objet de paquet qui sera utilisé comme remplaçant de ce paquet. Voir grafts, pour plus de détails.

synopsis

Une description sur une ligne du paquet.

description

Une description plus détaillée du paquet, en tant que chaine au format Texinfo.

license ¶

La licence du paquet ; une valeur tirée de (guix licenses) ou une liste de ces valeurs.

home-page

L’URL de la page d’accueil du paquet, en tant que chaîne de caractères.

supported-systems (par défaut : %supported-systems)

La liste des systèmes supportés par le paquet, comme des chaînes de caractères de la forme architecture-noyau, par exemple "x86_64-linux".

location (par défaut : emplacement de la source de la forme package)

L’emplacement de la source du paquet. C’est utile de le remplacer lorsqu’on hérite d’un autre paquet, auquel cas ce champ n’est pas automatiquement corrigé.

Macro :this-package

Lorsque vous l’utilisez dans la portée lexicale du champ d’une définition de paquet, cet identifiant est résolu comme étant le paquet définit.

L’exemple ci-dessous montre l’ajout d’un paquet comme entrée native de lui-même pour la compilation croisée :

(package
  (name "guile")
  ;; ...

  ;; Lors de la compilation croisée, Guile par exemple dépend
  ;; d'une version native de lui-même. On l'ajoute ici.
  (native-inputs (if (%current-target-system)
                     (list this-package)
                     '())))

C’est une erreur que de se référer à this-package en dehors de la définition d’un paquet.

Les procédures auxiliaires suivantes vous aideront à utiliser les entrées des paquets.

Procédure :lookup-package-input package name

Procédure :lookup-package-native-input package name

Procédure :lookup-package-propagated-input package name

Procédure :lookup-package-direct-input package name

Cherche name dans les entrées de package (ou les entrées natives, propagées ou directes). Renvoie l’entrée si elle la trouve, et #f sinon.

name est le nom d’un paquet de dépendance. Voici comment vous pouvez l’utiliser :

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

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

Dans cet exemple, on obtient le paquet gmp qui fait partie des entrées directes de coreutils.

Parfois vous voudrez obtenir la liste des entrées requises pour développer un paquet — toutes les entrées visibles quand le paquet est compilé. C’est ce que la procédure package-development-inputs renvoie.

Procédure :package-development-inputs package [system] [#:target #f]

Renvoie la liste des entrées requises par package pour le développement sur system. Lorsque target est vrai, les entrées renvoyées sont celles requises pour la compilation croisée de package de system vers target, où target est un triplet comme "aarch64-linux-gnu".

Remarquez que le résultat inclus à la fois les entrées explicites et implicites — les entrées ajoutées automatiquement par le système de construction (voir Systèmes de construction). Prenons le paquet hello pour illustrer :

(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 …>) …)

Dans cet exemple, package-direct-inputs renvoie la liste vide, parce que hello n’a pas de dépendance explicite. À l’inverse, package-development-inputs inclut les entrées implicites ajoutées par gnu-build-system qui sont requises pour construire hello : tar, gzip, GCC, libc, Bash et d’autres. Pour les visualiser, guix graph hello montrerait les entrées explicites, alors que guix graph -t bag hello inclurait les entrées implicites (voir Invoque guix graph).

Comme les paquets sont des objets Scheme réguliers qui capturent un graphe de dépendance complet et les procédures de construction associées, il est souvent utile d’écrire des procédures qui prennent un paquet et renvoient une version modifiée de celui-ci en fonction de certains paramètres. En voici quelques exemples.

Procédure :package-with-c-toolchain package toolchain

Renvoie une variante de package qui utilise toolchain au lieu de la chaîne d’outils GNU C/C++ par défaut. toolchain doit être une liste d’entrées (tuples label/package) fournissant une fonctionnalité équivalente, comme le paquet gcc-toolchain.

L’exemple ci-dessous renvoie une variante du paquet hello construit avec GCC 10.x et le reste de la chaîne d’outils GNU (Binutils et la bibliothèque C GNU) au lieu de la chaîne d’outils par défaut :

(let ((toolchain (specification->package "gcc-toolchain@10")))
  (package-with-c-toolchain hello `(("toolchain" ,toolchain))))

La chaîne d’outils de construction fait partie des entrées implicites des paquets— elle n’est généralement pas listée comme faisant partie des différents champs "entrées" et est à la place récupérée par le système de construction. Par conséquent, cette procédure fonctionne en modifiant le système de compilation de paquet de sorte qu’il utilise toolchain au lieu des valeurs par défaut. Systèmes de construction, pour en savoir plus sur les systèmes de construction.