On Sat, May 08, 2004 at 07:47:47PM +0200, JusTiCe8 wrote: > Sylvain LE GALL wrote: > > >Bonjour, > > > >On Sat, May 08, 2004 at 04:33:39PM +0200, JusTiCe8 wrote: > > > > > >>Bonjour, > >> > >>attention risque d'apparition d'un gros troll méchant pas beaux, j'aurai > >>prévenu ;). > >> > >> > >> > > > >Pkoi un troll ? Ca me parait un trés bonne question, qui n'a pas de > >raison de faire un troll. > > > > > > > en raison de la rivalité sous jacente Gnome/KDE ;) > > > > >Ben en fait c'est trés simple, > > > >C'est une question d'API. Les API de libpngX et libpngY ( X != Y ) sont > >incompatibles ( je ne parles pas des paquets de dev ). La c'est trés > >simple, puisque le fichier qui contient ces API ( à savoir les .so ) > >portent la marque de la version ( .X ou .Y + dans le fichier ) et son > >géré par ld. > > > >Donc pour les librairies y a pas de pb. > > > >En revanche, et c'est la que ca se corse, les API des fichiers header > >sont aussi différents, mais peuvent ne pas l'être suffisament pour > >empécher une compil ( ie généralement le cas quand une fonction initX() > >faisait A + B et que pour des raisons quelconques elle fait plus que A > >mais il faut faire B quand même à la main, ca se voit pas, mais ca fait > >un SIGSEGV ). > > > >Et la, c'est rare que le fichiers headers porte la marque de leur version, > >ou plutot c'est compliqué qu'il porte la marque de leur version : > >- les fichiers headers sont souvent dans /usr/include/ ( png.h par ex ) > >- tous les progs qui utilisent un header l'utilisent explicitement ( ou > > presque ) #include <png.h> > > > >Donc si les headers porté la marque de leur version, comme avec ld, ca > >serait bien, mais il faudrait une certaines forme de gestion de la > >version ( note ca existe, ca s'appelle pkgconfig, avec lequel tu fais > >pkgconfig "gtk2.0 > 2.0.0" par exemple" ). La plupart des programmes > >n'utilisant pas ce type de chose, ben on se trouve dans la nécessité > >d'avoir recour à des libs exclusives ( parcequ'elles ont le meme fichier > >header qu'elles installent au meme endroit ). > > > >Note : ce type de probleme peut se résoudre avec des bons > >configure/config.h/Makefile... Mais pour penser à tous et faire des > >programmes parfait c'est difficile. > > > >Voila ma réponse -- peut etre fausse > > > > > fausse je ne pense pas, mais qui ne répond pas à mes questions plutôt. >
Je pensais répondre à cette partie : > >>Je me demandais si quelqu'un parmi vous pouvez m'expliquer le pourquoi > >>du comment de la présence des différentes libpngx-dev (x= ,2,3), leur > >>utilité et la raison pour laquelle un paquet A utilise une version y > >>plutôt que z (avantages/inconvénients). > >> Dans ma réponse, j'explique qu'une API évolue, et que les fonctions ne veulent plus dire la meme chose -> - avantage de garder l'ancienne = pas de changement ( tu rajoutes pas B ) - inconvénients = changement mais probablement moins de bugs... ( cf ma précédente réponse, c'est implicite, parceque de toute, facon il n'y a pas d'avantage / désavantage réelle, c'est qu'une question de langage ). > >>Aussi, et c'est la que c'est le plus embêtant, c'est que par un esprit > >>plus que tordu et, évidemment ;), par le plus grand des hasard, les libs > >>qt3 (kde) dépendent d'une version (libpng-dev) et les lib gtk (gnome) > >>d'une autre (libpng2-dev), ces 2 versions étant conflictuelles. > >> > >>Pour ma part, je pense que c'est une abérration de voir une chose pareil > >>et c'est plus que saoûlant de devoir viré des libs de dev qt pour > >>compiler une appli gtk et vice-versa. Surtout que la solution du > >>chroot-ing me parait un peu lourde dans ce genre de cas. > >> Ben non, c'est pas forcément une abérration, un changement d'API ca peut amener des bonnes choses, ou des mauvaises choses, c'est donc pour ca qu'il faut des 2-dev et 3-dev. Aprés le fait qu'il ne soit pas installable en même temps, c'est une question de conflits de fichier installé, principalement ! ( cf ma précédente réponse ). Cordialement Sylvain Le Gall