Un exemple concret: un projet qui a été développé sur une version de Debian qui est maintenant la oldstable. Il a besoin d'une vieille version de perl et de GNU make, entre autres.
Il est beaucoup plus simple de dire aux nouveaux développeurs d'installer le système Linux de leur choix, puis de déployer la Debian oldstable à partir d'une image (ça pourrait être docket je suppose, mais en l'occurence c'est un truc avec un chroot et des scripts maison). Et ça marche tout seul, pas de maintenance à faire sur l'environnement.
On a clairement pas le temps de s'amuser à recompiler de vieilles versions de Perl, make, du compilateur croisé utilisé, etc. D'ailleurs, par exemple, il est impossible (enfin, compliqué, en faisant plein de patches, peut-être) de compiler un gcc 4.5 ou antérieur pour x86_64 avec un gcc récent. Et oui, on peut avoir besoin de ce genre de choses, par exemple si on maintient un produit avec un CPU 68hc11, qui n'est pas supporté par un gcc actuel et pour lequel on doit pouvoir avoir au mieux un gcc 3.4, de mémoire (les patches n'ont jamais été intégrés dans le gcc officiel).
Donc voilà, l'environnement de dev, il est comme ça, il changera pas, et il fait sa vie. ça coûte rien à maintenir tant que le noyau Linux ne change pas ses appels systèmes et qu'on trouve des CPU x86 compatibles avec les binaires qui sont dedans.
[^] # Re: Dockerfiles
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 4.
Un exemple concret: un projet qui a été développé sur une version de Debian qui est maintenant la oldstable. Il a besoin d'une vieille version de perl et de GNU make, entre autres.
Il est beaucoup plus simple de dire aux nouveaux développeurs d'installer le système Linux de leur choix, puis de déployer la Debian oldstable à partir d'une image (ça pourrait être docket je suppose, mais en l'occurence c'est un truc avec un chroot et des scripts maison). Et ça marche tout seul, pas de maintenance à faire sur l'environnement.
On a clairement pas le temps de s'amuser à recompiler de vieilles versions de Perl, make, du compilateur croisé utilisé, etc. D'ailleurs, par exemple, il est impossible (enfin, compliqué, en faisant plein de patches, peut-être) de compiler un gcc 4.5 ou antérieur pour x86_64 avec un gcc récent. Et oui, on peut avoir besoin de ce genre de choses, par exemple si on maintient un produit avec un CPU 68hc11, qui n'est pas supporté par un gcc actuel et pour lequel on doit pouvoir avoir au mieux un gcc 3.4, de mémoire (les patches n'ont jamais été intégrés dans le gcc officiel).
Donc voilà, l'environnement de dev, il est comme ça, il changera pas, et il fait sa vie. ça coûte rien à maintenir tant que le noyau Linux ne change pas ses appels systèmes et qu'on trouve des CPU x86 compatibles avec les binaires qui sont dedans.