Définition des paquets (Manuel de référence de GNU Guix)

9.2 Définition des paquets

L’interface de haut-niveau pour les définitions de paquets est implémentée dans les modules (guix packages) et (guix build-system). Par exemple, la définition du paquet, ou la recette, du paquet GNU Hello ressemble à cela :

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs (list gawk))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

Sans être expert·e en Scheme, on peut comprendre la signification des différents champs présents. Cette expression lie la variable hello à un objet <package>, qui est en substance un enregistrement (voir Scheme records dans GNU Guile Reference Manual). On peut inspecter cet objet de paquet avec les procédures qui se trouvent dans le module (guix packages) ; par exemple, (package-name hello) renvoie — ô surprise ! — "hello".

Avec un peu de chance, vous pourrez importer tout ou partie de la définition du paquet qui vous intéresse depuis un autre répertoire avec la commande guix import (voir Invoquer guix import).

Dans l’exemple précédent, hello est défini dans un module à part, (gnu packages hello). Techniquement, cela n’est pas strictement nécessaire, mais c’est pratique : tous les paquets définis dans des modules sous (gnu packages …) sont automatiquement connus des outils en ligne de commande (voir Modules de paquets).

Il y a quelques points à remarquer dans la définition de paquet précédente :

Le champ source du paquet est un objet <origin> (voir Référence de origin, pour la référence complète). Ici, on utilise la méthode url-fetch de (guix download), ce qui signifie que la source est un fichier à télécharger par FTP ou HTTP.
Le préfixe mirror://gnu demande à url-fetch d’utiliser l’un des miroirs GNU définis dans (guix download).

Le champ sha256 spécifie le hash SHA256 attendu pour le fichier téléchargé. Il est requis et permet à Guix de vérifier l’intégrité du fichier. La forme (base32 …) introduit a représentation en base32 du hash. Vous pouvez obtenir cette information avec guix download (voir Invoquer guix download) et guix hash (voir Invoquer guix hash).

Lorsque cela est requis, la forme origin peut aussi avec un champ patches qui liste les correctifs à appliquer et un champ snippet qui donne une expression Scheme pour modifier le code source.
Le champ build-system spécifie la procédure pour construire le paquet (voir Systèmes de construction). Ici, gnu-build-system représente le système de construction GNU familier, où les paquets peuvent être configurés, construits et installés avec la séquence ./configure && make && make check && make install habituelle.
Lorsque vous commencez à empaqueter des logiciels non triviaux, vous pouvez avoir besoin d’outils pour manipuler ces phases de construction, manipuler des fichiers, etc. Voir Utilitaires de construction, pour en savoir plus.
Le champ arguments spécifie des options pour le système de construction (voir Systèmes de construction). Ici il est interprété par gnu-build-system comme une demande de lancer configure avec le tag --enable-silent-rules.
Que sont ces apostrophes (') ? C’est de la syntaxe Scheme pour introduire une liste ; ' est synonyme de la fonction quote. Parfois vous verrez aussi ` (un accent grave synonyme de quasiquote) et , (une virgule, synonyme de unquote). Voir quoting dans GNU Guile Reference Manual, pour des détails. Ice la valeur du champ arguments est une liste d’arguments passés au système de construction plus tard, comme avec apply (voir apply dans GNU Guile Reference Manual).

La séquence dièse-deux-points (#:) définie un mot-clef Scheme (voir Keywords dans GNU Guile Reference Manual), et #:configure-flags est un mot-clef utilisé pour passer un argument au système de construction (voir Coding With Keywords dans GNU Guile Reference Manual).
Le champ inputs spécifie les entrées du processus de construction — c.-à-d. les dépendances à la construction ou à l’exécution du paquet. Ici, nous ajoutons en entrée une référence à la variable gawk ; gawk est lui-même lié à un objet <package>.
Remarquez que GCC, Coreutils, Bash et les autres outils essentiels n’ont pas besoin d’être spécifiés en tant qu’entrées ici. À la place, le gnu-build-system est en mesure de s’assurer qu’ils sont présents (voir Systèmes de construction).

Cependant, toutes les autres dépendances doivent être spécifiées dans le champ inputs. Toute dépendance qui ne serait pas spécifiée ici sera simplement indisponible pour le processus de construction, ce qui peut mener à un échec de la construction.

Voir Référence de package, pour une description complète des champs possibles.

Pour aller plus loin : Vous vous sentez intimidé·e par le langage Scheme ou vous êtes curieux·se de le découvrir ? Le livre de recettes a une petite section pour démarrer qui résume une partie de ce qui a été montré au-dessus et explique les bases. Voir Cours accéléré du langage Scheme dans le livre de recettes de GNU Guix, pour plus d’information.

Lorsqu’une définition de paquet est en place, le paquet peut enfin être construit avec l’outil en ligne de commande guix build (voir Invoquer guix build), pour résoudre les échecs de construction que vous pourriez rencontrer (voir Débogage des échecs de construction). Vous pouvez aisément revenir à la définition du paquet avec la commande guix edit (voir Invoquer guix edit). Voir Consignes d’empaquetage, pour plus d’informations sur la manière de tester des définitions de paquets et Invoquer guix lint, pour des informations sur la manière de vérifier que la définition respecte les conventions de style. Enfin, voir Canaux pour des informations sur la manière d’étendre la distribution en ajoutant vos propres définitions de paquets dans un « canal ».

Finalement, la mise à jour de la définition du paquet à une nouvelle version amont peut en partie s’automatiser avec la commande guix refresh (voir Invoquer guix refresh).

Sous le capot, une dérivation qui correspond à un objet <package> est d’abord calculé par la procédure package-derivation. Cette dérivation est stockée dans un fichier .drv dans /gnu/store. Les actions de construction qu’il prescrit peuvent ensuite être réalisées par la procédure build-derivation (voir Le dépôt).

Procédure Scheme :package-derivation store package [system]

Renvoie l’objet <derivation> du paquet pour le système (voir Dérivations).

paquet doit être un objet <package> valide et système une chaîne indiquant le type de système cible — p. ex. "x86_64-linux" pour un système GNU x86_64 basé sur Linux. dépôt doit être une connexion au démon, qui opère sur les dépôt (voir Le dépôt).

De manière identique, il est possible de calculer une dérivation qui effectue une compilation croisée d’un paquet pour un autre système :

Procédure Scheme :package-cross-derivation store paquet cible [système] renvoie l'objet <derivation>

du paquet construit depuis système pour cible.

cible doit être un triplet GNU valide indiquant le matériel cible et le système d’exploitation, comme "aarch64-linux-gnu" (voir Specifying Target Triplets dans Autoconf).

Une fois qu’on a une définition de paquet, on peut facilement définir des variantes du paquet. Voir Définition de variantes de paquets, pour plus d’informations.