Au final ça semble se résumer à :
On ne peut pas faire les choses comme on veut, parce que ça peut avoir un impact sur la pléthore de logiciels, d'outils, et de personnes (et d'emplois !) qui dépendent de comment les choses sont faites.
Et donc Mesa a atteint un point où ils doivent absolument faire attention à ne pas casser les fonctionnements actuels, et donc se poser la question des usages, et tester en amont la compatibilité de leurs changements.
Par chance pour eux, ça se fait alors qu'il y a des entreprises impliquées dans le projet, et des personnes payées pour bosser sur le projet, donc ce n'est pas une problématique bénévole, et travail gratuit pour des entreprises, ici.
Pour ce qui est du problème de mise à jour de zlib en interne, comme bien expliqué dans plusieurs des commentaires sur Phoronix, des solutions techniques il y en a, il va suffire de faire les choses un peu différemment et voilà.
Si ça peut leur permettre de séparer un peu plus la tambouille interne des interfaces externes, ça ne peut être que positif.
Parce que si j'ai bien compris, le lien dynamique avec une version trop récente de zlib, va casser un outil répandu qui a aussi besoin de zlib, mais pas à la même version, et boum.
Ce n'est pas un problème insurmontable, et il pourrait même paraître gênant qu'une contrainte interne à un outil soit en conflit avec une contrainte interne à un autre outil : chacun sa tambouille.
# Beaucoup de bruit ?
Posté par Yth (Mastodon) . En réponse au lien Mesa : la rançon du succès. Évalué à 8.
Au final ça semble se résumer à :
On ne peut pas faire les choses comme on veut, parce que ça peut avoir un impact sur la pléthore de logiciels, d'outils, et de personnes (et d'emplois !) qui dépendent de comment les choses sont faites.
Et donc Mesa a atteint un point où ils doivent absolument faire attention à ne pas casser les fonctionnements actuels, et donc se poser la question des usages, et tester en amont la compatibilité de leurs changements.
Par chance pour eux, ça se fait alors qu'il y a des entreprises impliquées dans le projet, et des personnes payées pour bosser sur le projet, donc ce n'est pas une problématique bénévole, et travail gratuit pour des entreprises, ici.
Pour ce qui est du problème de mise à jour de zlib en interne, comme bien expliqué dans plusieurs des commentaires sur Phoronix, des solutions techniques il y en a, il va suffire de faire les choses un peu différemment et voilà.
Si ça peut leur permettre de séparer un peu plus la tambouille interne des interfaces externes, ça ne peut être que positif.
Parce que si j'ai bien compris, le lien dynamique avec une version trop récente de zlib, va casser un outil répandu qui a aussi besoin de zlib, mais pas à la même version, et boum.
Ce n'est pas un problème insurmontable, et il pourrait même paraître gênant qu'une contrainte interne à un outil soit en conflit avec une contrainte interne à un autre outil : chacun sa tambouille.
Voilà mon résumé, en français, des débats.