Sinon concernant les tests, la quasi majorités des logiciels libres importants sont aujourd'hui couvert par un nombre de tests suffisamment important pour garantir leur bon fonctionnement dans un environnement donnée
Les tests vont peut-être exister.
Est-ce que les tests unitaires seront lancés lors du build de l’image ? Déjà c’est loin d’être garanti.
Est-ce que les tests d’intégration (ie du binaire final dans libc+kernel d’exécution) le seront ? Quasiment certains que non.
encore faut-il que les sysadmins se donne la peine de réaliser ces mises à jours compte tenu du risque que cela représente. Quand tu as la possibilité de réaliser ces mises à jours dans une environnement reproductible, tu n'as plus aucune raison pour ne pas les faire étant données que tu as toujours la possibilité de revenir en arrière si dans le pire des cas tu observais un problème après avoir effectué l'upgrade.
Au contraire.
Tu n’as justement plus aucune raison de les faire avec FlatPak, parce que ton appli fonctionne toujours avec la vieille lib chez tous tes utilisateurs.
Alors que tu es contraint de faire le portage sous Debian ou Arch si tu ne veux pas voir ton appli se faire virer des dépôts.
D’autant plus que j’ai déjà montré plus haut que la reproductibilité ne s’applique que pour une image donnée dans un hôte d’exécution donné.
Tu n’as plus aucune reproductibilité (ie que ton application qui fonctionnait en v1 fonctionne toujours en v2), en tout cas pas garantie, quand tu passes d’une v1.x à une v2.x sur le soft ou une dépendance ou que tu changes l’hôte d’exécution.
Un soft qui tourne parfaitement en glibc peut se tauler magistralement μclibc.
Un soft qui tourne parfaitement avec libssl 1.1.x peut ne même pas compiler en 1.2.x.
Un soft qui tourne parfaitement sur une Debian 9 (libc 2.24) peut ne pas fonctionner en Debian 8 (2.19) ou en Debian 10 (2.27) ou sous Arch (2.28), même FlatPakisée.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 3.
Les tests vont peut-être exister.
Est-ce que les tests unitaires seront lancés lors du build de l’image ? Déjà c’est loin d’être garanti.
Est-ce que les tests d’intégration (ie du binaire final dans libc+kernel d’exécution) le seront ? Quasiment certains que non.
Au contraire.
Tu n’as justement plus aucune raison de les faire avec FlatPak, parce que ton appli fonctionne toujours avec la vieille lib chez tous tes utilisateurs.
Alors que tu es contraint de faire le portage sous Debian ou Arch si tu ne veux pas voir ton appli se faire virer des dépôts.
D’autant plus que j’ai déjà montré plus haut que la reproductibilité ne s’applique que pour une image donnée dans un hôte d’exécution donné.
Tu n’as plus aucune reproductibilité (ie que ton application qui fonctionnait en v1 fonctionne toujours en v2), en tout cas pas garantie, quand tu passes d’une v1.x à une v2.x sur le soft ou une dépendance ou que tu changes l’hôte d’exécution.
Un soft qui tourne parfaitement en glibc peut se tauler magistralement μclibc.
Un soft qui tourne parfaitement avec libssl 1.1.x peut ne même pas compiler en 1.2.x.
Un soft qui tourne parfaitement sur une Debian 9 (libc 2.24) peut ne pas fonctionner en Debian 8 (2.19) ou en Debian 10 (2.27) ou sous Arch (2.28), même FlatPakisée.