> Tu pointes du doigt un problème important, celui de la multiplication des version des librairies.
scoop : la même librairie avec le même numéro de version dans deux distributions ne sera en fait pas la même. parce que l'une aura mis le support du Zorglub et l'autre non. mais bref.
> 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.
"sans comprendre leurs difficultés", vraiment ? j'ai fait le tour des rôles, là, tu vois, codeur packageur utilisateur documentation et assurer le support de personnes qui ne lisaient même pas le readme.txt qui était dans l'archive livrée et recopiée sur la page de téléchargement. pour du libre comme du commercial. depuis plus de 10 ans. ou 15.
à la bonne vieille époque il n'y avait pas de GNU/Linux mais une vingtaine d'Unix POSIX et on va dire que bien peu ont survécu. pour tenter d'installer des trucs comme unzip il fallait en général taper make lenomdelOS. et définir à la main quel compilateur on allait utiliser, parce que gcc était par endroit une vraie rareté.
> Je te rappelle que notre plate-forme de développement n'est pas une distro particulière mais GNU/Linux.
chaque fois que tu diras ça, fous-toi un bon coup de marteau sur les burnes. ça te passera vite.
la plateforme GNU/Linux n'existe pas plus que la plateforme Unix ou la plateforme POSIX. c'est une chimère. et tu oublies les gens sous processeurs G3, G4, G5 et les gens sur des mobiles avec des processeurs ARM ou autres.
tu auras beau sortir cette expression de "GNU/Linux" tous les matins en te rasant, ça ne changera rien au fait que tes utilisateurs "sous GNU/Linux" sont en fait "sous Linux Mandriva 2006.1 x86 32 bits" ou un autre truc souvent aussi long. et je ne parle pas des petits monstres sans version fixe comme Debian sid, Mandriva Cooker et autres Gentoo à jour. la preuve, toi même tu utilises SDL. donc c'est "GNU/Linux/SDL" et compagnie ta plateforme, au bas mot. sauf qu'elle est unique à chez toi ou tes quelques compères développeurs.
et pour tes problèmes de SDL_Mixer j'ai presque l'impression que tu découvres la vie. une mise à jour d'une librairie, une version trop différente pour pouvoir comparer facilement, et boum, ton logiciel plante, et tu ne sais pas pourquoi. tu remarqueras que quand ton logiciel fait des trucs bien plus importants et critiques pour tes clients tu peux mystérieusement commencer à imposer un environnement strict, précis et qui ne bougera plus - en y conditionnant le support, par exemple.
il y a 10 ans pratiquement chaque application Windows était livré avec sa version de mfc40.dll (et quelques autres). parce que en résumé la leur ils étaient sûrs qu'elle marchait sur leur machine de test et ils ne pouvaient pas prévoir laquelle aurait le client. normalement ils l'installaient dans le répertoire de leur application et ça allait à peu près, elle était prioritaire. sauf les 5 % de crétins qui l'installaient dans c:\windows et là, boum ! les ennuis commençaient. depuis, cette blague est connue, mais on a eu droit à d'autres depuis.
croire que c'est parce que tu as un Installshield (ou un clone) qui te fabrique un joli .exe avec tous les fichiers qui font que ça marche chez toi que ça va marcher tout seul chez les autres, c'est de la fumette. j'en connais qui utilisent en dur "c:\windows" pour indiquer le répertoire de Windows, c'est dire...
même avec une ribambelle de bibliothèques rajoutées à la LSB, tu ne seras pas à l'abri de problèmes de portabilité que tu ne découvriras que chez tes utilisateurs. ça a été exactement pareil pour Java, bien qu'il était censé être portable tout ça tout ça. oh, il fallait juste se battre avec les / et les ,円 entre autres...
[^] # Re: Utilisation des applications sans 'installation'
Posté par Gniarf . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 0.
scoop : la même librairie avec le même numéro de version dans deux distributions ne sera en fait pas la même. parce que l'une aura mis le support du Zorglub et l'autre non. mais bref.
> 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.
"sans comprendre leurs difficultés", vraiment ? j'ai fait le tour des rôles, là, tu vois, codeur packageur utilisateur documentation et assurer le support de personnes qui ne lisaient même pas le readme.txt qui était dans l'archive livrée et recopiée sur la page de téléchargement. pour du libre comme du commercial. depuis plus de 10 ans. ou 15.
à la bonne vieille époque il n'y avait pas de GNU/Linux mais une vingtaine d'Unix POSIX et on va dire que bien peu ont survécu. pour tenter d'installer des trucs comme unzip il fallait en général taper make lenomdelOS. et définir à la main quel compilateur on allait utiliser, parce que gcc était par endroit une vraie rareté.
> Je te rappelle que notre plate-forme de développement n'est pas une distro particulière mais GNU/Linux.
chaque fois que tu diras ça, fous-toi un bon coup de marteau sur les burnes. ça te passera vite.
la plateforme GNU/Linux n'existe pas plus que la plateforme Unix ou la plateforme POSIX. c'est une chimère. et tu oublies les gens sous processeurs G3, G4, G5 et les gens sur des mobiles avec des processeurs ARM ou autres.
tu auras beau sortir cette expression de "GNU/Linux" tous les matins en te rasant, ça ne changera rien au fait que tes utilisateurs "sous GNU/Linux" sont en fait "sous Linux Mandriva 2006.1 x86 32 bits" ou un autre truc souvent aussi long. et je ne parle pas des petits monstres sans version fixe comme Debian sid, Mandriva Cooker et autres Gentoo à jour. la preuve, toi même tu utilises SDL. donc c'est "GNU/Linux/SDL" et compagnie ta plateforme, au bas mot. sauf qu'elle est unique à chez toi ou tes quelques compères développeurs.
et pour tes problèmes de SDL_Mixer j'ai presque l'impression que tu découvres la vie. une mise à jour d'une librairie, une version trop différente pour pouvoir comparer facilement, et boum, ton logiciel plante, et tu ne sais pas pourquoi. tu remarqueras que quand ton logiciel fait des trucs bien plus importants et critiques pour tes clients tu peux mystérieusement commencer à imposer un environnement strict, précis et qui ne bougera plus - en y conditionnant le support, par exemple.
il y a 10 ans pratiquement chaque application Windows était livré avec sa version de mfc40.dll (et quelques autres). parce que en résumé la leur ils étaient sûrs qu'elle marchait sur leur machine de test et ils ne pouvaient pas prévoir laquelle aurait le client. normalement ils l'installaient dans le répertoire de leur application et ça allait à peu près, elle était prioritaire. sauf les 5 % de crétins qui l'installaient dans c:\windows et là, boum ! les ennuis commençaient. depuis, cette blague est connue, mais on a eu droit à d'autres depuis.
croire que c'est parce que tu as un Installshield (ou un clone) qui te fabrique un joli .exe avec tous les fichiers qui font que ça marche chez toi que ça va marcher tout seul chez les autres, c'est de la fumette. j'en connais qui utilisent en dur "c:\windows" pour indiquer le répertoire de Windows, c'est dire...
même avec une ribambelle de bibliothèques rajoutées à la LSB, tu ne seras pas à l'abri de problèmes de portabilité que tu ne découvriras que chez tes utilisateurs. ça a été exactement pareil pour Java, bien qu'il était censé être portable tout ça tout ça. oh, il fallait juste se battre avec les / et les ,円 entre autres...