Re: libpng*-dev et conflits
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
Reply to: