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. Cela é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 y a des fonctions auxiliaires pour faire cela avec les
paquets qui utilisent git-fetch
ou hg-fetch
(voir plus
bas). 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))))
;; …
)))
Renvoie la chaîne de version pour les paquets qui utilisent
git-fetch
.
(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05") ⇒ "0.2.3-0.93818c9"
Renvoie la chaîne de version pour les paquets qui utilisent
hg-fetch
. Cela fonctionne de la même manière que git-fetch
.
Suivant: Synopsis et descriptions, Précédent: Conventions de nommage, Monter: Consignes d’empaquetage [Table des matières][Index]