L'isolation des dépendances à au moins l'avantage de permettre la reproductibilité de l’environnement, de pouvoir exécuter des tests dans un environnement contrôlé et rentre tout processus de mise à jour automatisable plus facilement.
Pour moi c’est justement exactement le contraire.
L’embarquement des dépendances pose la question de la glibc et du kernel utilisés.
La compatibilité entre versions y est plutôt bonne mais pas garantie et tu t’exposes à des crashs totalement incompréhensibles d’une machine à l’autre si tu utilises un binaire compilé avec une glibc qui n’est pas celle utilisée par le kernel de ta machine. Cf ici pour le détail du problème de compatibilité.
La garantie de reproductibilité vient donc de sauter (et encore pire sous Docker avec des trucs type Alpine/μClibc quand le dev a toutes les chances d’utiliser et de tester sous glibc).
Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
Peu de monde s’amuse à changer ses fichiers de dépendances pour mettre à jour avec la dernière version connue.
Généralement, les gens ne rebuildent que sur des changements de version upstream de l’application (et non d’une des dépendances) et ne changent les versions des dépendances que sur une version majeure de l’application (et non d’une dépendance).
Je ne connais d’ailleurs pas de process de build capable d’aller détecter un changement de dépendances de manière fiable, et encore moins capable de garantir que l’image finale est toujours fonctionnelle avec la nouvelle version. C’est un processus relativement très manuel qui nécessite de revalider l’ensemble de l’applicatif suite à un tel changement, et l’automatisation demanderait des tests d’intégration très couvrants pour ça, ce qu’on a généralement jamais.
Ton idée de maj auto vient de sauter aussi du coup.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . En réponse au journal Flatpak. Évalué à 1.
Pour moi c’est justement exactement le contraire.
L’embarquement des dépendances pose la question de la glibc et du kernel utilisés.
La compatibilité entre versions y est plutôt bonne mais pas garantie et tu t’exposes à des crashs totalement incompréhensibles d’une machine à l’autre si tu utilises un binaire compilé avec une glibc qui n’est pas celle utilisée par le kernel de ta machine. Cf ici pour le détail du problème de compatibilité.
La garantie de reproductibilité vient donc de sauter (et encore pire sous Docker avec des trucs type Alpine/μClibc quand le dev a toutes les chances d’utiliser et de tester sous glibc).
Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
Peu de monde s’amuse à changer ses fichiers de dépendances pour mettre à jour avec la dernière version connue.
Généralement, les gens ne rebuildent que sur des changements de version upstream de l’application (et non d’une des dépendances) et ne changent les versions des dépendances que sur une version majeure de l’application (et non d’une dépendance).
Je ne connais d’ailleurs pas de process de build capable d’aller détecter un changement de dépendances de manière fiable, et encore moins capable de garantir que l’image finale est toujours fonctionnelle avec la nouvelle version. C’est un processus relativement très manuel qui nécessite de revalider l’ensemble de l’applicatif suite à un tel changement, et l’automatisation demanderait des tests d’intégration très couvrants pour ça, ce qu’on a généralement jamais.
Ton idée de maj auto vient de sauter aussi du coup.