Tu lances ta commande, tu obtiens un binaire. Est-ce le même qu’hier ? Tu es incapable de le dire. As-tu buildé une v1.0.0 ou une de tes dépendances a-t-elle bougée et tu as alors compilé une v1.0.1 malgré que tu aies indiqué v1.0.0 dans ton fichier de build ?
Au contraire, tu maitrises cette partie. Tant que tu ne fais de pull, ton environnement local sera fige. C'est le contraire d'apt, ou un simple apt upgrade fait que justement, un meme binaire peut avoir des comportements differents suivant les jours. Le cas est rare certes, mais la reproductibilité est clairement une force des containers.
Pour l’exemple de FreeCAD, ça donne par exemple plus de 180 versions sur 1 an, dont les dépendances divergent rapidement passées 1 semaine d’écart.
Juste ça en prod, tu oublies. Vraiment.
C'est ce que tu as deja en prod. Vraiment.
L'avantage, c'est qu'au moins, tu délivres des configs cohérentes a tes utilisateurs, des configs que tu peux tester et reproduire.
Et à l’inverse assez mal le mainteneur de FreeCAD se dire « Oh , un heartbleed sauvage apparaît. FreeCAD snap, en avant ! ».
Encore une fois, les ppa pourront detecter ce genre de dependance et relancer une build. Le mainteneur n'aura rien a faire.
[^] # Re: Mise-à-jour de sécurité sous snap
Posté par flagos . En réponse au journal Mon premier snap sur Xenial. Évalué à 2.
Au contraire, tu maitrises cette partie. Tant que tu ne fais de pull, ton environnement local sera fige. C'est le contraire d'apt, ou un simple apt upgrade fait que justement, un meme binaire peut avoir des comportements differents suivant les jours. Le cas est rare certes, mais la reproductibilité est clairement une force des containers.
C'est ce que tu as deja en prod. Vraiment.
L'avantage, c'est qu'au moins, tu délivres des configs cohérentes a tes utilisateurs, des configs que tu peux tester et reproduire.
Encore une fois, les ppa pourront detecter ce genre de dependance et relancer une build. Le mainteneur n'aura rien a faire.