• [^] # Re: Plusieurs questions

    Posté par . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 2.

    Pour info, je veux pas avoir l'air de faire mon lourd à toujours vous comparer avec flatpak. C'est simplement que c'est le seul aussi système de paquet/conteneur que je connais bien. Donc j'essaie juste de comprendre les différences entre guix et flatpak parce que je connais pas grand chose d'autre dans cette catégorie.

    Je fais les mêmes remarques que roptat formulées un peu différemment. En espérant que cela aide à mieux cerner les différences. Sachant que je ne suis pas un utilisateur de flatpack.

    Pour faire simple, flatpack construit sur un runtime/SDK et donc quel est le contrôle sur cela ? Quelle est la version du compilateur C ? Comment cela a-t-il été bootstrappé ?

    Liens bootstrap: dans Guix ou généralement pour le C ou l'effort pour Rust.

    Si je comprends bien, avec les lignes 4-6 de org.gimp.GIMP.json un environnement est tiré qui contient un certain nombre de binaires. Est-ce que dans disons 2 ans, si cet environnement n'est plus disponible en ligne, sera-t-on capable de le reconstruire à l'identique (bit-to-bit) ?

    Si on considère un dockerfile (finalement très similaire à flatpack me semble-t-il), ce fichier/recette utilise disons une image Debian stable, et depuis le 22 juillet 2017, il y a eu 9 mises à jour mineures de la version stable, dont 3 "mises à jour" de la glibc, et 1 mise à jour de GCC, python2.7 et python3.5. Sans compter je ne sais combien de paquets supprimés (voir ici). Sauf erreur de ma part, aujourd'hui, on est incapable de reconstruire from scratch l'image Debian telle qu'elle était disons le 5 mars 2019.

    Par ailleurs, disons que Gimp dépende de Python3.5 qui a besoin de GCC pour être construit; ces 2 sont fournit pour le SDK. Gimp est construit avec ce SDK, disons SDK1. Puis imaginons que GCC recoive un patch de sécurité et Python3.5 est donc reconstruit avec cette "nouvelle" version de GCC, ce qui donne un SDK2. Ce changement est l'objet d'un commit dans le Gitlab de Freedesktop-SDK mais les mainteneurs ne changent pas la version du SDK, cela ne le mérite pas vraiment. Avec la même recette (qui ne dépend pas du commit ni runtime ni SDK mais uniquement de la version et oups! les mainteneurs ne l'ont pas changée), Gimp est maintenant construit avec ce SDK2. Et oh surprise, un bug apparait dans le Gimp-SDK2 et pas le Gimp-SDK1. Tout semble identique en apparence. Mais la chaine de dépendance n'est pas exactement la même. flatpack ne semble pas capable de le détecter. Est-ce exact ?

    Ensuite oui dans un runtime, y a très probablement plus que nécessaire. Ça part évidemment du principe qu'un runtime est utilisé par de multiples applications et permet au contraire de partager la charge

    Certes. Et en plus il faut aussi remarquer si 2 applications partagent une même dépendance (qui n'est pas dans le runtime), son mode de construction sera spécifiée à 2 endroits bien différents. Ceci a l'avantage d'avoir des bundles/application bien séparés; qui peuvent vivre leur vie chacune de leur côté. Et ceci à l'inconvénient de ne pas être mutualisé et donc de refaire du boulot déjà fait par d'autres.

    Dans GNU Guix, on cherche à mutualiser toutes les briques pour pouvoir les composer. Au plus juste si on peut dire. :-)

    Finalement, mon impression sans jamais avoir utilisé flatpack est que cela correspond à guix pack sans la machinerie de la reproductibilité bit-à-bit.