Suivant: Synopsis et descriptions, Précédent: Conventions de nommage, Monter: Consignes d'empaquetage [Table des matières][Index]
Nous n’incluons en général que la dernière version d’un projet de logiciel
libre donné. Mais parfois, par exemple pour des versions incompatibles de
bibliothèques, deux (ou plus) versions du même paquet sont requises. Elles
ont besoin d’un nom de variable Scheme différent. Nous utilisons le nom
défini dans Conventions de nommage pour la version la plus récente ; les
versions précédentes utilisent le même nom, suffixé par -
et le plus
petit préfixe du numéro de version qui permet de distinguer deux versions.
Le nom dans la définition du paquet est le même pour toutes les versions d’un paquet et ne contient pas de numéro de version.
Par exemple, les version 2.24.20 et 3.9.12 de GTK+ peuvent être inclus de cette manière :
(define-public gtk+ (package (name "gtk+") (version "3.9.12") ...)) (define-public gtk+-2 (package (name "gtk+") (version "2.24.20") ...))
Si nous voulons aussi GTK+ 3.8.2, cela serait inclus de cette manière
Parfois, nous incluons des paquets provenant d’instantanés de systèmes de
contrôle de version (VCS) au lieu de versions publiées formellement. Cela
devrait rester exceptionnel, car c’est le rôle des développeurs amont de
spécifier quel est la version stable. Cependant, c’est parfois nécessaire.
Donc, que faut-il mettre dans le champ version
?
Clairement, nous devons rendre l’identifiant de commit de l’instantané du
VCS visible dans la version, mais nous devons aussi nous assurer que la
version augmente de manière monotone pour que guix package
--upgrade
puisse déterminer quelle version est la plus récente. Comme les
identifiants de commits, notamment avec Git, n’augmentent pas, nous ajoutons
un numéro de révision qui nous augmentons à chaque fois que nous mettons à
jour vers un nouvel instantané. La chaîne qui en résulte ressemble à cela :
2.0.11-3.cabba9e ^ ^ ^ | | `-- ID du commit en amont | | | `--- révision du paquet Guix | dernière version en amont
C’est une bonne idée de tronquer les identifiants dans le champ
version
à disons 7 caractères. Celà évite un problème esthétique (en
supposant que l’esthétique ait un rôle à jouer ici) et des problèmes avec
les limites de l’OS comme la longueur maximale d’un shebang (127 octets pour
le noyau Linux). Il vaut mieux cependant utiliser l’identifiant de commit
complet dans origin
, pour éviter les ambiguïtés. Une définition de
paquet peut ressembler à ceci :
(define my-package
(let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
(revision "1")) ;révision du paquet Guix
(package
(version (git-version "0.9" revision commit))
(source (origin
(method git-fetch)
(uri (git-reference
(url "git://example.org/my-package.git")
(commit commit)))
(sha256 (base32 "1mbikn…"))
(file-name (git-file-name name version))))
;; …
)))
Suivant: Synopsis et descriptions, Précédent: Conventions de nommage, Monter: Consignes d'empaquetage [Table des matières][Index]