Le noyau lui-même n'est effectivement pas pris en compte dans le modèle, mais il y a assez peu de problèmes de compatibilité entre versions. L'ensemble des services qui tournent sur la machines peuvent aussi être problématiques, mais encore une fois, leur compatibilité casse assez peu souvent.
Pour le reste, c'est un peu plus compliqué. Tous les paquets sont installés dans le dépôt, une arborescence de fichier en ajout-seul (sauf pour le ramasse-miettes, qui a le droit de supprimer ce qui n'est utilisé par aucune génération des profils sur le système). Quand je construis un paquet, je vais en fait l'ajouter au dépôt dans un chemin de la forme /gnu/store/<hash>-<nom>/. Par exemple, pour le paquet hello, j'ai actuellement /gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10.
L'une des dépendances de hello, c'est la bibliothèque C (glibc), et on peut s'en rendre compte en regardant les détails du fichier binaire:
$ file /gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10/bin/hello
/gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10/bin/hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
Comme on peut le voir, le fichier fait directement référence à ld-linux-x86-64.so.2 dans le dépôt, et non à un fichier installé de manière globale sur le système, comme pourrait l'être /lib/ld-linux-x86-64.so.2 par exemple. Ça veut dire que, quoi qu'il arrive autour de ce paquet, il fera toujours référence à la même bibliothèque standard C. Il en va de même pour toutes ses dépendances.
Ce chemin vers la bibliothèque standard C ne vient pas de nul part : le paquet est compilé à partir d'une recette qui vient d'une version précise de Guix. Le chemin est question est celui qui provient de la recette de glibc dans la même révision de Guix. Si une future révision de Guix met à jour la recette de glibc (par exemple en la mettant à jour), cela modifie l'entrée correspondante pour le paquet hello. Le paquet hello qui serait construit à partir de cette nouvelle version ferait alors référence directement à la glibc de cette nouvelle révision de Guix.
Quand on met à jour son système, on met à jour la révision de Guix et on reconstruit tous les paquets dont les entrées ont changés (récursivement). À chaque mise à jour les nouvelles variantes des paquets font bien référence aux nouvelles variantes de leurs dépendances (ou les anciennes si elles n'ont pas changé), ce qui garanti que tout est bien mis à jour. Les anciens paquets qui ne sont plus nécessaires peuvent être récoltés par le ramasse-miettes.
Mais c'est aussi pour cela que l'article dit qu'un paquet construit une fois ne peut pas casser : tant qu'il est dans le dépôt, il fait référence aux paquets qui l'ont construit, et pas des versions différentes. On a donc l'avantage des deux mondes : du partage autant que possible pour les paquets d'une même révision de Guix, mais les dépendances sont préservées à leur version d'origine pour les paquets qui ne peuvent pas être mis à jour.
[^] # Re: Le système d'exploitation du futur ?
Posté par roptat . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 3.
Le noyau lui-même n'est effectivement pas pris en compte dans le modèle, mais il y a assez peu de problèmes de compatibilité entre versions. L'ensemble des services qui tournent sur la machines peuvent aussi être problématiques, mais encore une fois, leur compatibilité casse assez peu souvent.
Pour le reste, c'est un peu plus compliqué. Tous les paquets sont installés dans le dépôt, une arborescence de fichier en ajout-seul (sauf pour le ramasse-miettes, qui a le droit de supprimer ce qui n'est utilisé par aucune génération des profils sur le système). Quand je construis un paquet, je vais en fait l'ajouter au dépôt dans un chemin de la forme
/gnu/store/<hash>-<nom>/. Par exemple, pour le paquet hello, j'ai actuellement/gnu/store/md2plii4g5sk66wg9cgwc964l3xwhrm9-hello-2.10.L'une des dépendances de hello, c'est la bibliothèque C (glibc), et on peut s'en rendre compte en regardant les détails du fichier binaire:
Comme on peut le voir, le fichier fait directement référence à ld-linux-x86-64.so.2 dans le dépôt, et non à un fichier installé de manière globale sur le système, comme pourrait l'être
/lib/ld-linux-x86-64.so.2par exemple. Ça veut dire que, quoi qu'il arrive autour de ce paquet, il fera toujours référence à la même bibliothèque standard C. Il en va de même pour toutes ses dépendances.Ce chemin vers la bibliothèque standard C ne vient pas de nul part : le paquet est compilé à partir d'une recette qui vient d'une version précise de Guix. Le chemin est question est celui qui provient de la recette de glibc dans la même révision de Guix. Si une future révision de Guix met à jour la recette de glibc (par exemple en la mettant à jour), cela modifie l'entrée correspondante pour le paquet hello. Le paquet hello qui serait construit à partir de cette nouvelle version ferait alors référence directement à la glibc de cette nouvelle révision de Guix.
Quand on met à jour son système, on met à jour la révision de Guix et on reconstruit tous les paquets dont les entrées ont changés (récursivement). À chaque mise à jour les nouvelles variantes des paquets font bien référence aux nouvelles variantes de leurs dépendances (ou les anciennes si elles n'ont pas changé), ce qui garanti que tout est bien mis à jour. Les anciens paquets qui ne sont plus nécessaires peuvent être récoltés par le ramasse-miettes.
Mais c'est aussi pour cela que l'article dit qu'un paquet construit une fois ne peut pas casser : tant qu'il est dans le dépôt, il fait référence aux paquets qui l'ont construit, et pas des versions différentes. On a donc l'avantage des deux mondes : du partage autant que possible pour les paquets d'une même révision de Guix, mais les dépendances sont préservées à leur version d'origine pour les paquets qui ne peuvent pas être mis à jour.