Tu pointes du doigt un problème important, celui de la multiplication des version des librairies.
En quoi est-ce un problème ? Les cycles de publications des versions stables des bibliothèques sont plutôt longs, surtout pour les versions mineures et majeures : pour les versions de patchs, je ne pense pas que tu ai besoin d'être aussi à jour (et ton co-développeur l'a déjà dit, sauf erreur). En outre, les développeurs de bibliothèques maintennent généralement la version précédente même après que la nouvelle branche ait débuté, tout comme Linux.
Je trouve domage que tu tapes de la sorte sur les développeurs sans comprendre aussi leur difficulté. Il sont dans l'incapacité de cibler une version spécifique de librairie car personne ne défini une référence commune.
Les développeurs n'ont pas besoin d'une référence commune, ils ont simplement besoin d'ABI et API qui correspondent à leurs besoins de programmation. S'ils ne savent plus à quelles bibliothèques se vouer, c'est qu'ils ont mal défini leurs besoins.
Je te rappelle que notre plate-forme de développement n'est pas une distro particulière mais GNU/Linux. Es tu capable de me dire quelle est la 'bonne' version de SDL_Mixer à utiliser en ce moment, tu n'en sais rien et moi non plus. Enfin, si je sais que c'est pas la 1.2.7 qui est packagé dans la plupart des distros car elle fait planter GCompris.
Non, c'est faux. La plate-forme de développement de tout développeur, à moins qu'il ne soit parti d'une base de LFS, est fatalement une des nombreuses distributions qui existent déjà.
En outre, à moins qu'il ne se contruise un environnement protégé ("chroot", "jail", ce qu'il veut) pour faire son développement, il devra forcément composer avec les bibliothèques fournies par la distribution ou les compiler lui-même (ce qui rentre un peu dans le cas de l'environnement "protégé"). Et si son application a besoin d'une bibliothèque qui n'est pas encore disponible dans la distribution, il appartiendra aux responsables de paquets volontaires de faire le nécessaire pour combler le manque. Or : si ton application est bien censée fonctionner avec la version Y de bilbliothèque X, je ne vois pas pourquoi ils ne parviendraient pas à créer le paquet binaire eux-mêmes.
J'ai de plus en plus la nette impression que tu ne veux/peux pas nous dire quel est ton véritable problème et but dans cette histoire, comme si tu avais des clients un peu exigeants.
Es tu capable de me dire quelle est la 'bonne' version de SDL_Mixer à utiliser en ce moment, tu n'en sais rien et moi non plus. Enfin, si je sais que c'est pas la 1.2.7 qui est packagé dans la plupart des distros car elle fait planter GCompris.
Si ton logiciel plante avec une version particulière de la distribution, ce n'est pas la faute du mode actuel de distribution des logiciels libres mais plutôt entre GCompris et SDL. Sous Debian sid, c'est encore la 1.2.6 : tu devrais peut-être te demander pourquoi la 1.2.7 n'y est pas encore...
La seule est unique solution pour avoir des logiciels stable sur une plate-forme stable c'est de ne pas tout mélanger comme nous le faisons actuellement. Il nous faut un coeur de librairies les plus courantes, bien définies et que les projets peuvent cibler. En dehors de cela, il faut que chaque projet livre ses librairies car il est sûr que son projet marche avec. Certe c'est pas optimisé et on ne va pas faire ça pour tous les logiciels mais ça doit être une option possible et simple à faire, à la fois pour les développeurs mais aussi pour les utilisateurs. Bien sûr on a besoin d'un bonne intégration dans la distro.
Il y a un détail qui me choque dans ce paragraphe : à quoi servira-t-il d'avoir des distributions si la base LSB suffit amplement aux développeurs ? Et qu'adviendra-t-il le jour où les développeurs auront besoin d'une version à jour de la bibliothèque X parce qu'elle implément la toute nouvelle fonctionnalité Y ? Crois-tu qu'ils feront en sorte que la base LSB soit mise à jour ? On peut en douter et combien même serait-ce le cas, il est bien possible que la base LSB refuse de mettre à jour la dite bibliothèque pour des raisons de stabilité de la dite base qui sert de référence : chose que tu demandes aussi...
Je souhaite bien du plaisir à Ian Murdock.
[^] # Re: Utilisation des applications sans 'installation'
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 2.
En quoi est-ce un problème ? Les cycles de publications des versions stables des bibliothèques sont plutôt longs, surtout pour les versions mineures et majeures : pour les versions de patchs, je ne pense pas que tu ai besoin d'être aussi à jour (et ton co-développeur l'a déjà dit, sauf erreur). En outre, les développeurs de bibliothèques maintennent généralement la version précédente même après que la nouvelle branche ait débuté, tout comme Linux.
Les développeurs n'ont pas besoin d'une référence commune, ils ont simplement besoin d'ABI et API qui correspondent à leurs besoins de programmation. S'ils ne savent plus à quelles bibliothèques se vouer, c'est qu'ils ont mal défini leurs besoins.
Non, c'est faux. La plate-forme de développement de tout développeur, à moins qu'il ne soit parti d'une base de LFS, est fatalement une des nombreuses distributions qui existent déjà.
En outre, à moins qu'il ne se contruise un environnement protégé ("chroot", "jail", ce qu'il veut) pour faire son développement, il devra forcément composer avec les bibliothèques fournies par la distribution ou les compiler lui-même (ce qui rentre un peu dans le cas de l'environnement "protégé"). Et si son application a besoin d'une bibliothèque qui n'est pas encore disponible dans la distribution, il appartiendra aux responsables de paquets volontaires de faire le nécessaire pour combler le manque. Or : si ton application est bien censée fonctionner avec la version Y de bilbliothèque X, je ne vois pas pourquoi ils ne parviendraient pas à créer le paquet binaire eux-mêmes.
J'ai de plus en plus la nette impression que tu ne veux/peux pas nous dire quel est ton véritable problème et but dans cette histoire, comme si tu avais des clients un peu exigeants.
Si ton logiciel plante avec une version particulière de la distribution, ce n'est pas la faute du mode actuel de distribution des logiciels libres mais plutôt entre GCompris et SDL. Sous Debian sid, c'est encore la 1.2.6 : tu devrais peut-être te demander pourquoi la 1.2.7 n'y est pas encore...
Il y a un détail qui me choque dans ce paragraphe : à quoi servira-t-il d'avoir des distributions si la base LSB suffit amplement aux développeurs ? Et qu'adviendra-t-il le jour où les développeurs auront besoin d'une version à jour de la bibliothèque X parce qu'elle implément la toute nouvelle fonctionnalité Y ? Crois-tu qu'ils feront en sorte que la base LSB soit mise à jour ? On peut en douter et combien même serait-ce le cas, il est bien possible que la base LSB refuse de mettre à jour la dite bibliothèque pour des raisons de stabilité de la dite base qui sert de référence : chose que tu demandes aussi...
Je souhaite bien du plaisir à Ian Murdock.