Par contre, qu'en est-il des patchs downstream? De la signature du packageur?
Si je prend par exemple Debian, le format des paquets binaire en lui-même est vraiment simple.
L'ensemble des paquets de la distributions sont présents dans un dépôt git. Chaque commit doit être signé par la personne qui le pousse et nous avons des lignes directrices assez strictes quant à la qualité des recettes et des logiciels inclus dans la distribution. Il n'y a pas de paquets binaires à proprement dit : seulement des recettes. Le projet a deux fermes de construction qui publient les paquets qu'elles construisent et les signent avec leur propre clef. L'utilisateur est libre d'accorder sa confiance à une ferme de construction ou non.
On parle de transparence binaire : comme les paquets sont reproductibles, à partir de la même recette (et du même commit de guix), il est impossible de distinguer un paquet construit localement d'un paquet construit à distance. On peut donc soit construire le paquet localement, soit utiliser un « substitut binaire », qui remplace la construction du paquet. Grâce à ça, on peut aussi vérifier que les fermes de constructions ne sont pas corrompues en construisant un paquet localement et en défiant les fermes de construction, de cette manière :
guix challenge python-oauthlib python-polib python-tornado --substitute-urls="https://mirror.hydra.gnu.org https://ci.guix.gnu.org"
mise à jour des substituts depuis « https://mirror.hydra.gnu.org »... 100.0 %
mise à jour des substituts depuis « https://ci.guix.gnu.org »... 100.0 %
3 éléments du dépôt ont été analysés :
- 3 (100.0 %) étaient identiques
- 0 (0.0 %) étaient différents
- 0 (0.0 %) étaient impossibles à évaluer
Ça permet de se rassurer et d'ajouter un peu plus de confiance dans les fermes de construction. Chaque utilisateur peut aussi publier les paquets binaires qu'il a construit localement ou substitués, en les signant avec sa propre clef, que d'autres utilisateurs peuvent autoriser.
Par contre, faire un paquet Debian qui respecte les exigences de qualité Debian est plus chiant, ne serait-ce que la customisation des règles (fichier debian/rules) qui doit être en accord avec le fichier de conrôle (debian/control) ça rend les choses assez pénibles pour que, personnellement, au taf et pour ma pomme, je compile via cmake/autotools/scons/whatever et empaquette les binaires directement (coucou, libsdl2!).
L'une des raisons de la pénibilité des paquets source de Debian, selon moi, c'est la gestion des patchs, qui sont je pense nécessaires à une distro de type cyclique (pour une rolling, ce serait probablement trop pénible à gérer).
Impossible d'empaqueter des paquets binaires avec guix : tout doit utiliser des recettes, l'équivalent de debian/rules. Le but de ce gestionnaire de paquets est avant tout la transparence, et un paquet binaire n'est pas transparent du tout. D'ailleurs c'est plus généralement le but du projet reproducible-builds.
Pour les correctifs, effectivement on en a assez peu puisqu'on a un modèle de type cyclique. On peut cependant en ajouter dans l'enregistrement origin que je montrais plus haut, par exemple :
et le fichier se trouve à un endroit bien précis dans l'arborescence des sources de guix ou du canal qui possède ce paquet.
Une autre est la gestion des transitions, mais il me semble que Guix règle le problème avec des hash mis au bout des dossiers dépaquetés? Ou alors est-ce juste Nix? Toujours est-il que la gestion des transitions dans Debian est, je pense, remarquable, et aussi complexe à implémenter pour les daemons, tout en permettant un système très propre (un paquet ne restera pas installé en doublon ou sans raison sans demande explicite de l'admin). Que fait Guix de ce côté?
Sous guix (comme nix), les paquets sont présents dans le dépôt (/gnu/store ou /nix/store). Il peut y avoir dans le dépôt plus de paquets que nécessaire, mais j'y viens. En tant qu'utilisateur j'ai un profil de paquets (et même, je pourrais en créer plusieurs) dans lequel ne sont présents que les paquets que j'ai explicitement demandé, mais pas leurs dépendances, car les paquets se réfèrent à leurs dépendances directement avec leur chemin dans le dépôt. Chaque modification du profil crée une nouvelle génération, et on peut instantanément revenir à une génération antérieure ou postérieure. On peut aussi, quand on n'en a plus besoin, supprimer d'anciennes générations pour faire de la place.
Donc, avec guix remove qui « supprime » un paquet, je ne retire pas un paquet de mon profil, je crée une nouvelle génération qui contient les mêmes paquets qu'avant, sauf ceux que j'ai supprimés : rien n'est supprimé du dépôt. En supprimant des générations, je retire simplement la possibilité de revenir à elles, mais rien n'est supprimé du dépôt non plus. Pour supprimer des éléments du dépôt et faire de la place, on peut lancer guix gc qui va automatiquement déterminer les éléments du dépôt qui ne sont plus accessible depuis au moins une génération d'un profil et les supprimer, un peu comme le ferait autoclean avec le cache de debian. À noter que comme seuls les paquets explicitement demandés par l'utilisateur sont installés, il n'y a pas besoin d'équivalent à autoremove.
[^] # Re: Nix et autres
Posté par roptat . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 4.
L'ensemble des paquets de la distributions sont présents dans un dépôt git. Chaque commit doit être signé par la personne qui le pousse et nous avons des lignes directrices assez strictes quant à la qualité des recettes et des logiciels inclus dans la distribution. Il n'y a pas de paquets binaires à proprement dit : seulement des recettes. Le projet a deux fermes de construction qui publient les paquets qu'elles construisent et les signent avec leur propre clef. L'utilisateur est libre d'accorder sa confiance à une ferme de construction ou non.
On parle de transparence binaire : comme les paquets sont reproductibles, à partir de la même recette (et du même commit de guix), il est impossible de distinguer un paquet construit localement d'un paquet construit à distance. On peut donc soit construire le paquet localement, soit utiliser un « substitut binaire », qui remplace la construction du paquet. Grâce à ça, on peut aussi vérifier que les fermes de constructions ne sont pas corrompues en construisant un paquet localement et en défiant les fermes de construction, de cette manière :
Ça permet de se rassurer et d'ajouter un peu plus de confiance dans les fermes de construction. Chaque utilisateur peut aussi publier les paquets binaires qu'il a construit localement ou substitués, en les signant avec sa propre clef, que d'autres utilisateurs peuvent autoriser.
Impossible d'empaqueter des paquets binaires avec guix : tout doit utiliser des recettes, l'équivalent de
debian/rules. Le but de ce gestionnaire de paquets est avant tout la transparence, et un paquet binaire n'est pas transparent du tout. D'ailleurs c'est plus généralement le but du projet reproducible-builds.Pour les correctifs, effectivement on en a assez peu puisqu'on a un modèle de type cyclique. On peut cependant en ajouter dans l'enregistrement origin que je montrais plus haut, par exemple :
et le fichier se trouve à un endroit bien précis dans l'arborescence des sources de guix ou du canal qui possède ce paquet.
Sous guix (comme nix), les paquets sont présents dans le dépôt (
/gnu/storeou/nix/store). Il peut y avoir dans le dépôt plus de paquets que nécessaire, mais j'y viens. En tant qu'utilisateur j'ai un profil de paquets (et même, je pourrais en créer plusieurs) dans lequel ne sont présents que les paquets que j'ai explicitement demandé, mais pas leurs dépendances, car les paquets se réfèrent à leurs dépendances directement avec leur chemin dans le dépôt. Chaque modification du profil crée une nouvelle génération, et on peut instantanément revenir à une génération antérieure ou postérieure. On peut aussi, quand on n'en a plus besoin, supprimer d'anciennes générations pour faire de la place.Donc, avec
guix removequi « supprime » un paquet, je ne retire pas un paquet de mon profil, je crée une nouvelle génération qui contient les mêmes paquets qu'avant, sauf ceux que j'ai supprimés : rien n'est supprimé du dépôt. En supprimant des générations, je retire simplement la possibilité de revenir à elles, mais rien n'est supprimé du dépôt non plus. Pour supprimer des éléments du dépôt et faire de la place, on peut lancerguix gcqui va automatiquement déterminer les éléments du dépôt qui ne sont plus accessible depuis au moins une génération d'un profil et les supprimer, un peu comme le feraitautocleanavec le cache de debian. À noter que comme seuls les paquets explicitement demandés par l'utilisateur sont installés, il n'y a pas besoin d'équivalent àautoremove.