| 1 |
On Fri, 20 Jan 2006 10:54:40 +0100 |
| 2 |
Jean-Philippe ROPA <ehouf@×××××××.fr> wrote: |
| 3 |
|
| 4 |
> La logique voudrait que mon système ait 3 slots de gtk+ : |
| 5 |
> 1.2.10-r11, 2.6.10-r1 et 2.8.8 |
| 6 |
> |
| 7 |
> Je ne sais pas si j'ai été clair, mais là j'ai l'impression que |
| 8 |
> portage a une petite faiblesse. |
| 9 |
|
| 10 |
Il n'y a que deux SLOTs pour gtk+, un pour la branche 1.x et un |
| 11 |
pour la branche 2.x. Ça n'est pas une faiblesse de Portage, mais ça |
| 12 |
reflète simplement la nature des paquets gtk+ : |
| 13 |
- si tu regardes les contenus des paquets gtk+-1.x et gtk+-2.x, tu |
| 14 |
verras qu'ils sont complètement indépendants (les fichiers de |
| 15 |
/usr/includes en particuliers ne sont pas au même endroit). Pas de |
| 16 |
problème pour les sloter donc, il ne se marcheront pas sur les |
| 17 |
pieds l'un l'autre. |
| 18 |
- si tu regardes au contraire les contenus d'un gtk+-2.6.x et d'un |
| 19 |
gtk+-2.8.x, tu verras qu'ils sont très proches : la quasi totalité |
| 20 |
des fichiers headers sont communs par exemple. À partir de là, |
| 21 |
impossible de les sloter, puisque ça ferait 2 paquets qui écrasent |
| 22 |
l'un l'autre partie de leurs fichiers. |
| 23 |
|
| 24 |
Mais ça n'est pas un problème, c'est même fait pour : les versions |
| 25 |
2.x sont rétro-compatibles (sauf cas hyper tordu comme celui de |
| 26 |
libxfcegui, mais c'est quand même hyper rare), et les logiciels qui |
| 27 |
les utilisent ont donc juste à spécifier une version minimum, et |
| 28 |
ensuite ne s'en préocupent plus (les "# include machin.h" sont les |
| 29 |
même pour toutes les versions, ils se linkent sur des libs du |
| 30 |
style "libgtk-x11-2.0.so" qui sont fournies par toutes les |
| 31 |
versions 2.x, etc. Et c'est une bonne chose d'avoir toutes les |
| 32 |
applis gtk+-2.x qui utilisent un seul ensemble de bibliothèques : |
| 33 |
on n'a pas 36 versions en mémoire par exemple. |
| 34 |
|
| 35 |
Enfin bref, c'est bien et c'est normal que ça soit comme ça : le |
| 36 |
cas libxfcegui est vraiment une exception (si tu regardes les |
| 37 |
détails, c'est plus la faute de libxfcegui qui utilisait |
| 38 |
directement un détail interne des version gtk+-2.6, que celle de |
| 39 |
gtk+), mais ça ne veut pas dire qu'il y a un vrai besoin de faire |
| 40 |
cohabiter plusieurs versions. Ici le seul vrai problème, c'est plus |
| 41 |
qu'une rapide correction sur libxfcegui4-4.2.2 effectuée il y a 3 |
| 42 |
mois ne soit toujours pas marquée stable pour la plupart des |
| 43 |
archis... Si ça avait été le cas, ton passage en gtk+-2.8 n'aurait |
| 44 |
pas soulevé autant de questions. Libre à toi d'ailleurs de faire un |
| 45 |
bug report pour l'équipe amd64, pour leur demander de faire ce |
| 46 |
changement : |
| 47 |
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2 |
| 48 |
|
| 49 |
-- |
| 50 |
TGL. |
| 51 |
|
| 52 |
-- |
| 53 |
gentoo-user-fr@g.o mailing list |
Archives