Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thomas de Grenier de Latour
On Thu, 19 Jan 2006 22:49:24 +0100 Jean-Philippe ROPA wrote:
je viens de constater un passage incéssant entre "x11-libs/gtk+-2.6.8" et "x11-libs/gtk+-2.6.10-r1"
Une façon souvent efficace de diagnostiquer ce genre de problème est de masquer le paquet dont tu ne veux pas : # echo "<x11-libs-gtk+-2.8" >> /etc/portage/package.mask Ensuite, quand tu feras ton "emerge -puD --newuse world", tu devrais recevoir un message d'erreur qui te mettra sur la voie.
-- TGL.
-- mailing list
On Thu, 19 Jan 2006 22:49:24 +0100
Jean-Philippe ROPA <ehouf@wanadoo.fr> wrote:
je viens de constater un passage incéssant
entre "x11-libs/gtk+-2.6.8" et "x11-libs/gtk+-2.6.10-r1"
Une façon souvent efficace de diagnostiquer ce genre de problème
est de masquer le paquet dont tu ne veux pas :
# echo "<x11-libs-gtk+-2.8" >> /etc/portage/package.mask
Ensuite, quand tu feras ton "emerge -puD --newuse world", tu
devrais recevoir un message d'erreur qui te mettra sur la voie.
On Thu, 19 Jan 2006 22:49:24 +0100 Jean-Philippe ROPA wrote:
je viens de constater un passage incéssant entre "x11-libs/gtk+-2.6.8" et "x11-libs/gtk+-2.6.10-r1"
Une façon souvent efficace de diagnostiquer ce genre de problème est de masquer le paquet dont tu ne veux pas : # echo "<x11-libs-gtk+-2.8" >> /etc/portage/package.mask Ensuite, quand tu feras ton "emerge -puD --newuse world", tu devrais recevoir un message d'erreur qui te mettra sur la voie.
-- TGL.
-- mailing list
Jean-Philippe ROPA
Thomas de Grenier de Latour a écrit :
On Thu, 19 Jan 2006 22:49:24 +0100 Jean-Philippe ROPA wrote:
je viens de constater un passage incéssant entre "x11-libs/gtk+-2.6.8" et "x11-libs/gtk+-2.6.10-r1"
Une façon souvent efficace de diagnostiquer ce genre de problème est de masquer le paquet dont tu ne veux pas : # echo "<x11-libs-gtk+-2.8" >> /etc/portage/package.mask Ensuite, quand tu feras ton "emerge -puD --newuse world", tu devrais recevoir un message d'erreur qui te mettra sur la voie.
J'ai essayé et là je ne comprend plus :
si j'ai gtk+-2.8.8 installé et que je masque gtk+-2.6.10-r1, emerge -pvuD --newuse world ne propose aucune mise à jour et si je démasque 2.6.10-r1 il revient.
Mieux, j'ai le même comportement dans l'autre sens. A savoir gtk+-2.6.10-r1 installé et gtk+-2.8.8 masqué : aucune mise à jour et si démasque gtk+-2.8.8 il y a mise à jour.
__________________________________________
Suite des tests :
gtk+-2.8.8 installé et gtk+-2.6.10-r1 non masqué, j'obtiens les dépendances suivantes : emerge -auDt --newuse world
These are the packages that I would merge, in reverse order:
Est-ce normal d'interdire les versions supérieures à 2.8 ?
Jean-Philippe ROPA
-- mailing list
Thomas de Grenier de Latour a écrit :
On Thu, 19 Jan 2006 22:49:24 +0100
Jean-Philippe ROPA <ehouf@wanadoo.fr> wrote:
je viens de constater un passage incéssant
entre "x11-libs/gtk+-2.6.8" et "x11-libs/gtk+-2.6.10-r1"
Une façon souvent efficace de diagnostiquer ce genre de problème
est de masquer le paquet dont tu ne veux pas :
# echo "<x11-libs-gtk+-2.8" >> /etc/portage/package.mask
Ensuite, quand tu feras ton "emerge -puD --newuse world", tu
devrais recevoir un message d'erreur qui te mettra sur la voie.
J'ai essayé et là je ne comprend plus :
si j'ai gtk+-2.8.8 installé et que je masque gtk+-2.6.10-r1,
emerge -pvuD --newuse world
ne propose aucune mise à jour et si je démasque 2.6.10-r1
il revient.
Mieux, j'ai le même comportement dans l'autre sens.
A savoir gtk+-2.6.10-r1 installé et gtk+-2.8.8 masqué : aucune mise à jour
et si démasque gtk+-2.8.8 il y a mise à jour.
__________________________________________
Suite des tests :
gtk+-2.8.8 installé et gtk+-2.6.10-r1 non masqué, j'obtiens
les dépendances suivantes :
emerge -auDt --newuse world
These are the packages that I would merge, in reverse order:
On Thu, 19 Jan 2006 22:49:24 +0100 Jean-Philippe ROPA wrote:
je viens de constater un passage incéssant entre "x11-libs/gtk+-2.6.8" et "x11-libs/gtk+-2.6.10-r1"
Une façon souvent efficace de diagnostiquer ce genre de problème est de masquer le paquet dont tu ne veux pas : # echo "<x11-libs-gtk+-2.8" >> /etc/portage/package.mask Ensuite, quand tu feras ton "emerge -puD --newuse world", tu devrais recevoir un message d'erreur qui te mettra sur la voie.
J'ai essayé et là je ne comprend plus :
si j'ai gtk+-2.8.8 installé et que je masque gtk+-2.6.10-r1, emerge -pvuD --newuse world ne propose aucune mise à jour et si je démasque 2.6.10-r1 il revient.
Mieux, j'ai le même comportement dans l'autre sens. A savoir gtk+-2.6.10-r1 installé et gtk+-2.8.8 masqué : aucune mise à jour et si démasque gtk+-2.8.8 il y a mise à jour.
__________________________________________
Suite des tests :
gtk+-2.8.8 installé et gtk+-2.6.10-r1 non masqué, j'obtiens les dépendances suivantes : emerge -auDt --newuse world
These are the packages that I would merge, in reverse order:
Est-ce normal d'interdire les versions supérieures à 2.8 ?
Jean-Philippe ROPA
-- mailing list
Thomas de Grenier de Latour
On Thu, 19 Jan 2006 23:52:09 +0100 Jean-Philippe ROPA wrote:
RDEPEND="<x11-libs/gtk+-2.8
Est-ce que tu as gtk+-1.2.x d'installé ? Car si oui, ceci expliquerait celà : - cas où "<gtk+-2.8" n'est pas masqué : gtk+-2.6.10 est la meilleure mise à jour de la dépendance, et est donc proposé (parceque "-uD" met à jour toutes les dépendances) ; - cas où "<gtk+-2.8" est masqué : gtk+-1.2 satisfait la dépendance, donc pas d'erreur, mais pas de mise à jour non plus parcequ'il n'y a aucune meilleure version d'accessible.
Conclusion : cette dépendance "<x11-libs-gtk+2.8" est complètement absurde. Si il est vraiment nécéssaire d'avoir une version "2.x avec x inférieur à 8", alors la seule solution correcte serait d'énumérer des versions tolérées, du genre : || ( =x11-libs/gtk+-2.6* =x11-libs/gtk+-2.4* =x11-libs/gtk+-2.2* ) Ceci parceque portage ne sait pas gérer les intervales de versions du style « entre 2.2 et 2.8 ».
Quant à l'explication de ce "<2.8", cf. ici : https://bugs.gentoo.org/show_bug.cgi?id2912
Si j'ai bien compris, l'incompatibilité est corrigée, et donc c'est ok de masquer <gtk+-2.8 pour que ça tombe en marche. Par contre, l'ebuild n'ayant pas été bumpé au moment de la correction, vérifie si tu l'as emergé avant ou après (tu dois pouvoir trouver la date limite dans le changelog), et ré-emerge le si tu es du mauvais côté.
-- TGL.
-- mailing list
On Thu, 19 Jan 2006 23:52:09 +0100
Jean-Philippe ROPA <ehouf@wanadoo.fr> wrote:
RDEPEND="<x11-libs/gtk+-2.8
Est-ce que tu as gtk+-1.2.x d'installé ? Car si oui, ceci
expliquerait celà :
- cas où "<gtk+-2.8" n'est pas masqué : gtk+-2.6.10 est la
meilleure mise à jour de la dépendance, et est donc proposé
(parceque "-uD" met à jour toutes les dépendances) ;
- cas où "<gtk+-2.8" est masqué : gtk+-1.2 satisfait la
dépendance, donc pas d'erreur, mais pas de mise à jour non plus
parcequ'il n'y a aucune meilleure version d'accessible.
Conclusion : cette dépendance "<x11-libs-gtk+2.8" est complètement
absurde. Si il est vraiment nécéssaire d'avoir une version "2.x
avec x inférieur à 8", alors la seule solution correcte serait
d'énumérer des versions tolérées, du genre :
|| ( =x11-libs/gtk+-2.6* =x11-libs/gtk+-2.4* =x11-libs/gtk+-2.2* )
Ceci parceque portage ne sait pas gérer les intervales de versions
du style « entre 2.2 et 2.8 ».
Quant à l'explication de ce "<2.8", cf. ici :
https://bugs.gentoo.org/show_bug.cgi?id2912
Si j'ai bien compris, l'incompatibilité est corrigée, et donc c'est
ok de masquer <gtk+-2.8 pour que ça tombe en marche. Par contre,
l'ebuild n'ayant pas été bumpé au moment de la correction, vérifie
si tu l'as emergé avant ou après (tu dois pouvoir trouver la date
limite dans le changelog), et ré-emerge le si tu es du mauvais côté.
On Thu, 19 Jan 2006 23:52:09 +0100 Jean-Philippe ROPA wrote:
RDEPEND="<x11-libs/gtk+-2.8
Est-ce que tu as gtk+-1.2.x d'installé ? Car si oui, ceci expliquerait celà : - cas où "<gtk+-2.8" n'est pas masqué : gtk+-2.6.10 est la meilleure mise à jour de la dépendance, et est donc proposé (parceque "-uD" met à jour toutes les dépendances) ; - cas où "<gtk+-2.8" est masqué : gtk+-1.2 satisfait la dépendance, donc pas d'erreur, mais pas de mise à jour non plus parcequ'il n'y a aucune meilleure version d'accessible.
Conclusion : cette dépendance "<x11-libs-gtk+2.8" est complètement absurde. Si il est vraiment nécéssaire d'avoir une version "2.x avec x inférieur à 8", alors la seule solution correcte serait d'énumérer des versions tolérées, du genre : || ( =x11-libs/gtk+-2.6* =x11-libs/gtk+-2.4* =x11-libs/gtk+-2.2* ) Ceci parceque portage ne sait pas gérer les intervales de versions du style « entre 2.2 et 2.8 ».
Quant à l'explication de ce "<2.8", cf. ici : https://bugs.gentoo.org/show_bug.cgi?id2912
Si j'ai bien compris, l'incompatibilité est corrigée, et donc c'est ok de masquer <gtk+-2.8 pour que ça tombe en marche. Par contre, l'ebuild n'ayant pas été bumpé au moment de la correction, vérifie si tu l'as emergé avant ou après (tu dois pouvoir trouver la date limite dans le changelog), et ré-emerge le si tu es du mauvais côté.
-- TGL.
-- mailing list
Jean-Philippe ROPA
Thomas de Grenier de Latour a écrit :
Si j'ai bien compris, l'incompatibilité est corrigée, et donc c'est ok de masquer <gtk+-2.8 pour que ça tombe en marche. Par contre, l'ebuild n'ayant pas été bumpé au moment de la correction, vérifie si tu l'as emergé avant ou après (tu dois pouvoir trouver la date limite dans le changelog), et ré-emerge le si tu es du mauvais côté.
Effectivement, j'ai gtk+-1.2.x d'installé.
Par contre, je ne comprends pas bien, ton dernier conseil.
J'ai pu constaté sur un autre ordi en x86 que la version stable installé est libxfcegui4-4.2.2-r1 et je n'ai pas ce problème récurrent de mise à jour. Par contre en amd64 la version stable est libxfcegui4-4.2.2, qui pose des problèmes.
Merci d'avance
Jean-Philippe ROPA
-- mailing list
Thomas de Grenier de Latour a écrit :
Si j'ai bien compris, l'incompatibilité est corrigée, et donc c'est
ok de masquer <gtk+-2.8 pour que ça tombe en marche. Par contre,
l'ebuild n'ayant pas été bumpé au moment de la correction, vérifie
si tu l'as emergé avant ou après (tu dois pouvoir trouver la date
limite dans le changelog), et ré-emerge le si tu es du mauvais côté.
Effectivement, j'ai gtk+-1.2.x d'installé.
Par contre, je ne comprends pas bien, ton dernier conseil.
J'ai pu constaté sur un autre ordi en x86 que la version
stable installé est libxfcegui4-4.2.2-r1 et je n'ai pas ce problème
récurrent de mise à jour. Par contre en amd64 la version stable
est libxfcegui4-4.2.2, qui pose des problèmes.
Si j'ai bien compris, l'incompatibilité est corrigée, et donc c'est ok de masquer <gtk+-2.8 pour que ça tombe en marche. Par contre, l'ebuild n'ayant pas été bumpé au moment de la correction, vérifie si tu l'as emergé avant ou après (tu dois pouvoir trouver la date limite dans le changelog), et ré-emerge le si tu es du mauvais côté.
Effectivement, j'ai gtk+-1.2.x d'installé.
Par contre, je ne comprends pas bien, ton dernier conseil.
J'ai pu constaté sur un autre ordi en x86 que la version stable installé est libxfcegui4-4.2.2-r1 et je n'ai pas ce problème récurrent de mise à jour. Par contre en amd64 la version stable est libxfcegui4-4.2.2, qui pose des problèmes.
Merci d'avance
Jean-Philippe ROPA
-- mailing list
Jean-Philippe ROPA
Thomas de Grenier de Latour a écrit :
On Thu, 19 Jan 2006 23:52:09 +0100 Jean-Philippe ROPA wrote:
RDEPEND="<x11-libs/gtk+-2.8
Est-ce que tu as gtk+-1.2.x d'installé ? Car si oui, ceci expliquerait celà : - cas où "<gtk+-2.8" n'est pas masqué : gtk+-2.6.10 est la meilleure mise à jour de la dépendance, et est donc proposé (parceque "-uD" met à jour toutes les dépendances) ; - cas où "<gtk+-2.8" est masqué : gtk+-1.2 satisfait la dépendance, donc pas d'erreur, mais pas de mise à jour non plus parcequ'il n'y a aucune meilleure version d'accessible.
Il y a un truc que je ne comprends pas :
un paquet A a besoin de gtk+-1.2.10-r11 donc installé un paquet B a besoin de <gtk+-2.8 donc mise à jour de gtk+-1.2.10-r11 vers gtk+-2.6.10-r1 tout en conservant gtk+-1.2.10-r11 utile pour A Puis arrive gtk+-2.8.8 en stable, donc mise à jour de gtk+-2.6.10-r1 vers gtk+-2.8.8, mais pourquoi suppression de gtk+-2.6.10-r1 utile pour B ?
La logique voudrait que mon système ait 3 slots de gtk+ : 1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que portage a une petite faiblesse.
Jean-Philippe ROPA
-- mailing list
Thomas de Grenier de Latour a écrit :
On Thu, 19 Jan 2006 23:52:09 +0100
Jean-Philippe ROPA <ehouf@wanadoo.fr> wrote:
RDEPEND="<x11-libs/gtk+-2.8
Est-ce que tu as gtk+-1.2.x d'installé ? Car si oui, ceci
expliquerait celà :
- cas où "<gtk+-2.8" n'est pas masqué : gtk+-2.6.10 est la
meilleure mise à jour de la dépendance, et est donc proposé
(parceque "-uD" met à jour toutes les dépendances) ;
- cas où "<gtk+-2.8" est masqué : gtk+-1.2 satisfait la
dépendance, donc pas d'erreur, mais pas de mise à jour non plus
parcequ'il n'y a aucune meilleure version d'accessible.
Il y a un truc que je ne comprends pas :
un paquet A a besoin de gtk+-1.2.10-r11 donc installé
un paquet B a besoin de <gtk+-2.8 donc mise à jour
de gtk+-1.2.10-r11 vers gtk+-2.6.10-r1 tout en conservant
gtk+-1.2.10-r11 utile pour A
Puis arrive gtk+-2.8.8 en stable, donc mise à jour de gtk+-2.6.10-r1
vers gtk+-2.8.8, mais pourquoi suppression de gtk+-2.6.10-r1 utile pour B ?
La logique voudrait que mon système ait 3 slots de gtk+ :
1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que portage
a une petite faiblesse.
On Thu, 19 Jan 2006 23:52:09 +0100 Jean-Philippe ROPA wrote:
RDEPEND="<x11-libs/gtk+-2.8
Est-ce que tu as gtk+-1.2.x d'installé ? Car si oui, ceci expliquerait celà : - cas où "<gtk+-2.8" n'est pas masqué : gtk+-2.6.10 est la meilleure mise à jour de la dépendance, et est donc proposé (parceque "-uD" met à jour toutes les dépendances) ; - cas où "<gtk+-2.8" est masqué : gtk+-1.2 satisfait la dépendance, donc pas d'erreur, mais pas de mise à jour non plus parcequ'il n'y a aucune meilleure version d'accessible.
Il y a un truc que je ne comprends pas :
un paquet A a besoin de gtk+-1.2.10-r11 donc installé un paquet B a besoin de <gtk+-2.8 donc mise à jour de gtk+-1.2.10-r11 vers gtk+-2.6.10-r1 tout en conservant gtk+-1.2.10-r11 utile pour A Puis arrive gtk+-2.8.8 en stable, donc mise à jour de gtk+-2.6.10-r1 vers gtk+-2.8.8, mais pourquoi suppression de gtk+-2.6.10-r1 utile pour B ?
La logique voudrait que mon système ait 3 slots de gtk+ : 1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que portage a une petite faiblesse.
Jean-Philippe ROPA
-- mailing list
Thomas de Grenier de Latour
On Fri, 20 Jan 2006 10:39:05 +0100 Jean-Philippe ROPA wrote:
J'ai pu constaté sur un autre ordi en x86 que la version stable installé est libxfcegui4-4.2.2-r1 et je n'ai pas ce problème récurrent de mise à jour. Par contre en amd64 la version stable est libxfcegui4-4.2.2, qui pose des problèmes.
Mmmh, t'as raison, et contrairement à ce que je disais (je me basais sur ce que j'avais compris du bug report, mais j'ai du comprendre de travers), c'est bien uniquement dans la -r1 que l'incompatibilité est corrigée, et la dépendance <2.8 supprimée. Bon bah donc clairement il faut que tu package.keywords cette version pour accepter ~amd64:
# echo "=xfce-base/libxfcegui4-4.2.2-r1 ~amd64"
/etc/portage/package.keywords
-- TGL.
-- mailing list
On Fri, 20 Jan 2006 10:39:05 +0100
Jean-Philippe ROPA <ehouf@wanadoo.fr> wrote:
J'ai pu constaté sur un autre ordi en x86 que la version
stable installé est libxfcegui4-4.2.2-r1 et je n'ai pas ce
problème récurrent de mise à jour. Par contre en amd64 la version
stable est libxfcegui4-4.2.2, qui pose des problèmes.
Mmmh, t'as raison, et contrairement à ce que je disais (je me
basais sur ce que j'avais compris du bug report, mais j'ai du
comprendre de travers), c'est bien uniquement dans la -r1 que
l'incompatibilité est corrigée, et la dépendance <2.8 supprimée.
Bon bah donc clairement il faut que tu package.keywords cette
version pour accepter ~amd64:
On Fri, 20 Jan 2006 10:39:05 +0100 Jean-Philippe ROPA wrote:
J'ai pu constaté sur un autre ordi en x86 que la version stable installé est libxfcegui4-4.2.2-r1 et je n'ai pas ce problème récurrent de mise à jour. Par contre en amd64 la version stable est libxfcegui4-4.2.2, qui pose des problèmes.
Mmmh, t'as raison, et contrairement à ce que je disais (je me basais sur ce que j'avais compris du bug report, mais j'ai du comprendre de travers), c'est bien uniquement dans la -r1 que l'incompatibilité est corrigée, et la dépendance <2.8 supprimée. Bon bah donc clairement il faut que tu package.keywords cette version pour accepter ~amd64:
# echo "=xfce-base/libxfcegui4-4.2.2-r1 ~amd64"
/etc/portage/package.keywords
-- TGL.
-- mailing list
Thomas de Grenier de Latour
On Fri, 20 Jan 2006 10:54:40 +0100 Jean-Philippe ROPA wrote:
La logique voudrait que mon système ait 3 slots de gtk+ : 1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que portage a une petite faiblesse.
Il n'y a que deux SLOTs pour gtk+, un pour la branche 1.x et un pour la branche 2.x. Ça n'est pas une faiblesse de Portage, mais ça reflète simplement la nature des paquets gtk+ : - si tu regardes les contenus des paquets gtk+-1.x et gtk+-2.x, tu verras qu'ils sont complètement indépendants (les fichiers de /usr/includes en particuliers ne sont pas au même endroit). Pas de problème pour les sloter donc, il ne se marcheront pas sur les pieds l'un l'autre. - si tu regardes au contraire les contenus d'un gtk+-2.6.x et d'un gtk+-2.8.x, tu verras qu'ils sont très proches : la quasi totalité des fichiers headers sont communs par exemple. À partir de là, impossible de les sloter, puisque ça ferait 2 paquets qui écrasent l'un l'autre partie de leurs fichiers.
Mais ça n'est pas un problème, c'est même fait pour : les versions 2.x sont rétro-compatibles (sauf cas hyper tordu comme celui de libxfcegui, mais c'est quand même hyper rare), et les logiciels qui les utilisent ont donc juste à spécifier une version minimum, et ensuite ne s'en préocupent plus (les "# include machin.h" sont les même pour toutes les versions, ils se linkent sur des libs du style "libgtk-x11-2.0.so" qui sont fournies par toutes les versions 2.x, etc. Et c'est une bonne chose d'avoir toutes les applis gtk+-2.x qui utilisent un seul ensemble de bibliothèques : on n'a pas 36 versions en mémoire par exemple.
Enfin bref, c'est bien et c'est normal que ça soit comme ça : le cas libxfcegui est vraiment une exception (si tu regardes les détails, c'est plus la faute de libxfcegui qui utilisait directement un détail interne des version gtk+-2.6, que celle de gtk+), mais ça ne veut pas dire qu'il y a un vrai besoin de faire cohabiter plusieurs versions. Ici le seul vrai problème, c'est plus qu'une rapide correction sur libxfcegui4-4.2.2 effectuée il y a 3 mois ne soit toujours pas marquée stable pour la plupart des archis... Si ça avait été le cas, ton passage en gtk+-2.8 n'aurait pas soulevé autant de questions. Libre à toi d'ailleurs de faire un bug report pour l'équipe amd64, pour leur demander de faire ce changement : http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
-- TGL.
-- mailing list
On Fri, 20 Jan 2006 10:54:40 +0100
Jean-Philippe ROPA <ehouf@wanadoo.fr> wrote:
La logique voudrait que mon système ait 3 slots de gtk+ :
1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que
portage a une petite faiblesse.
Il n'y a que deux SLOTs pour gtk+, un pour la branche 1.x et un
pour la branche 2.x. Ça n'est pas une faiblesse de Portage, mais ça
reflète simplement la nature des paquets gtk+ :
- si tu regardes les contenus des paquets gtk+-1.x et gtk+-2.x, tu
verras qu'ils sont complètement indépendants (les fichiers de
/usr/includes en particuliers ne sont pas au même endroit). Pas de
problème pour les sloter donc, il ne se marcheront pas sur les
pieds l'un l'autre.
- si tu regardes au contraire les contenus d'un gtk+-2.6.x et d'un
gtk+-2.8.x, tu verras qu'ils sont très proches : la quasi totalité
des fichiers headers sont communs par exemple. À partir de là,
impossible de les sloter, puisque ça ferait 2 paquets qui écrasent
l'un l'autre partie de leurs fichiers.
Mais ça n'est pas un problème, c'est même fait pour : les versions
2.x sont rétro-compatibles (sauf cas hyper tordu comme celui de
libxfcegui, mais c'est quand même hyper rare), et les logiciels qui
les utilisent ont donc juste à spécifier une version minimum, et
ensuite ne s'en préocupent plus (les "# include machin.h" sont les
même pour toutes les versions, ils se linkent sur des libs du
style "libgtk-x11-2.0.so" qui sont fournies par toutes les
versions 2.x, etc. Et c'est une bonne chose d'avoir toutes les
applis gtk+-2.x qui utilisent un seul ensemble de bibliothèques :
on n'a pas 36 versions en mémoire par exemple.
Enfin bref, c'est bien et c'est normal que ça soit comme ça : le
cas libxfcegui est vraiment une exception (si tu regardes les
détails, c'est plus la faute de libxfcegui qui utilisait
directement un détail interne des version gtk+-2.6, que celle de
gtk+), mais ça ne veut pas dire qu'il y a un vrai besoin de faire
cohabiter plusieurs versions. Ici le seul vrai problème, c'est plus
qu'une rapide correction sur libxfcegui4-4.2.2 effectuée il y a 3
mois ne soit toujours pas marquée stable pour la plupart des
archis... Si ça avait été le cas, ton passage en gtk+-2.8 n'aurait
pas soulevé autant de questions. Libre à toi d'ailleurs de faire un
bug report pour l'équipe amd64, pour leur demander de faire ce
changement :
http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
On Fri, 20 Jan 2006 10:54:40 +0100 Jean-Philippe ROPA wrote:
La logique voudrait que mon système ait 3 slots de gtk+ : 1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que portage a une petite faiblesse.
Il n'y a que deux SLOTs pour gtk+, un pour la branche 1.x et un pour la branche 2.x. Ça n'est pas une faiblesse de Portage, mais ça reflète simplement la nature des paquets gtk+ : - si tu regardes les contenus des paquets gtk+-1.x et gtk+-2.x, tu verras qu'ils sont complètement indépendants (les fichiers de /usr/includes en particuliers ne sont pas au même endroit). Pas de problème pour les sloter donc, il ne se marcheront pas sur les pieds l'un l'autre. - si tu regardes au contraire les contenus d'un gtk+-2.6.x et d'un gtk+-2.8.x, tu verras qu'ils sont très proches : la quasi totalité des fichiers headers sont communs par exemple. À partir de là, impossible de les sloter, puisque ça ferait 2 paquets qui écrasent l'un l'autre partie de leurs fichiers.
Mais ça n'est pas un problème, c'est même fait pour : les versions 2.x sont rétro-compatibles (sauf cas hyper tordu comme celui de libxfcegui, mais c'est quand même hyper rare), et les logiciels qui les utilisent ont donc juste à spécifier une version minimum, et ensuite ne s'en préocupent plus (les "# include machin.h" sont les même pour toutes les versions, ils se linkent sur des libs du style "libgtk-x11-2.0.so" qui sont fournies par toutes les versions 2.x, etc. Et c'est une bonne chose d'avoir toutes les applis gtk+-2.x qui utilisent un seul ensemble de bibliothèques : on n'a pas 36 versions en mémoire par exemple.
Enfin bref, c'est bien et c'est normal que ça soit comme ça : le cas libxfcegui est vraiment une exception (si tu regardes les détails, c'est plus la faute de libxfcegui qui utilisait directement un détail interne des version gtk+-2.6, que celle de gtk+), mais ça ne veut pas dire qu'il y a un vrai besoin de faire cohabiter plusieurs versions. Ici le seul vrai problème, c'est plus qu'une rapide correction sur libxfcegui4-4.2.2 effectuée il y a 3 mois ne soit toujours pas marquée stable pour la plupart des archis... Si ça avait été le cas, ton passage en gtk+-2.8 n'aurait pas soulevé autant de questions. Libre à toi d'ailleurs de faire un bug report pour l'équipe amd64, pour leur demander de faire ce changement : http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
-- TGL.
-- mailing list
Thomas de Grenier de Latour
On Fri, 20 Jan 2006 11:50:40 +0100 Jean-Philippe ROPA wrote:
Mais, la seule commande que je connaisse est : qlist gtk+ qui ne permet pas de spécifier la branche.
Y-aurait-il moyen de savoir quels sont les fichiers installés uniquement par telle ou telle branche ?
"equery" interprète les "atomes de dépendances" (la notation des versions qu'on retrouve dans les ebuilds et ailleurs), donc tu peux par exemple faire : # equery files "=x11-libs/gtk+-1.2*" # equery files "=x11-libs/gtk+-2*"
-- TGL.
-- mailing list
On Fri, 20 Jan 2006 11:50:40 +0100
Jean-Philippe ROPA <ehouf@wanadoo.fr> wrote:
Mais, la seule commande que je connaisse est : qlist gtk+
qui ne permet pas de spécifier la branche.
Y-aurait-il moyen de savoir quels sont les fichiers
installés uniquement par telle ou telle branche ?
"equery" interprète les "atomes de dépendances" (la notation des
versions qu'on retrouve dans les ebuilds et ailleurs), donc tu peux
par exemple faire :
# equery files "=x11-libs/gtk+-1.2*"
# equery files "=x11-libs/gtk+-2*"
On Fri, 20 Jan 2006 11:50:40 +0100 Jean-Philippe ROPA wrote:
Mais, la seule commande que je connaisse est : qlist gtk+ qui ne permet pas de spécifier la branche.
Y-aurait-il moyen de savoir quels sont les fichiers installés uniquement par telle ou telle branche ?
"equery" interprète les "atomes de dépendances" (la notation des versions qu'on retrouve dans les ebuilds et ailleurs), donc tu peux par exemple faire : # equery files "=x11-libs/gtk+-1.2*" # equery files "=x11-libs/gtk+-2*"
-- TGL.
-- mailing list
Jean-Philippe ROPA
Thomas de Grenier de Latour a écrit :
On Fri, 20 Jan 2006 10:54:40 +0100 Jean-Philippe ROPA wrote:
La logique voudrait que mon système ait 3 slots de gtk+ : 1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que portage a une petite faiblesse.
Il n'y a que deux SLOTs pour gtk+, un pour la branche 1.x et un pour la branche 2.x. Ça n'est pas une faiblesse de Portage, mais ça reflète simplement la nature des paquets gtk+ : - si tu regardes les contenus des paquets gtk+-1.x et gtk+-2.x, tu verras qu'ils sont complètement indépendants (les fichiers de /usr/includes en particuliers ne sont pas au même endroit). Pas de problème pour les sloter donc, il ne se marcheront pas sur les pieds l'un l'autre. - si tu regardes au contraire les contenus d'un gtk+-2.6.x et d'un gtk+-2.8.x, tu verras qu'ils sont très proches : la quasi totalité des fichiers headers sont communs par exemple. À partir de là, impossible de les sloter, puisque ça ferait 2 paquets qui écrasent l'un l'autre partie de leurs fichiers.
Juste une dernière question, effectivement j'ai eu envie de voir les fichiers fournis par gtk+-1.x et gtk+-2.x
Mais, la seule commande que je connaisse est : qlist gtk+ qui ne permet pas de spécifier la branche.
Y-aurait-il moyen de savoir quels sont les fichiers installés uniquement par telle ou telle branche ?
Jean-Philippe ROPA
-- mailing list
Thomas de Grenier de Latour a écrit :
On Fri, 20 Jan 2006 10:54:40 +0100
Jean-Philippe ROPA <ehouf@wanadoo.fr> wrote:
La logique voudrait que mon système ait 3 slots de gtk+ :
1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que
portage a une petite faiblesse.
Il n'y a que deux SLOTs pour gtk+, un pour la branche 1.x et un
pour la branche 2.x. Ça n'est pas une faiblesse de Portage, mais ça
reflète simplement la nature des paquets gtk+ :
- si tu regardes les contenus des paquets gtk+-1.x et gtk+-2.x, tu
verras qu'ils sont complètement indépendants (les fichiers de
/usr/includes en particuliers ne sont pas au même endroit). Pas de
problème pour les sloter donc, il ne se marcheront pas sur les
pieds l'un l'autre.
- si tu regardes au contraire les contenus d'un gtk+-2.6.x et d'un
gtk+-2.8.x, tu verras qu'ils sont très proches : la quasi totalité
des fichiers headers sont communs par exemple. À partir de là,
impossible de les sloter, puisque ça ferait 2 paquets qui écrasent
l'un l'autre partie de leurs fichiers.
Juste une dernière question, effectivement j'ai eu envie
de voir les fichiers fournis par gtk+-1.x et gtk+-2.x
Mais, la seule commande que je connaisse est : qlist gtk+
qui ne permet pas de spécifier la branche.
Y-aurait-il moyen de savoir quels sont les fichiers
installés uniquement par telle ou telle branche ?
On Fri, 20 Jan 2006 10:54:40 +0100 Jean-Philippe ROPA wrote:
La logique voudrait que mon système ait 3 slots de gtk+ : 1.2.10-r11, 2.6.10-r1 et 2.8.8
Je ne sais pas si j'ai été clair, mais là j'ai l'impression que portage a une petite faiblesse.
Il n'y a que deux SLOTs pour gtk+, un pour la branche 1.x et un pour la branche 2.x. Ça n'est pas une faiblesse de Portage, mais ça reflète simplement la nature des paquets gtk+ : - si tu regardes les contenus des paquets gtk+-1.x et gtk+-2.x, tu verras qu'ils sont complètement indépendants (les fichiers de /usr/includes en particuliers ne sont pas au même endroit). Pas de problème pour les sloter donc, il ne se marcheront pas sur les pieds l'un l'autre. - si tu regardes au contraire les contenus d'un gtk+-2.6.x et d'un gtk+-2.8.x, tu verras qu'ils sont très proches : la quasi totalité des fichiers headers sont communs par exemple. À partir de là, impossible de les sloter, puisque ça ferait 2 paquets qui écrasent l'un l'autre partie de leurs fichiers.
Juste une dernière question, effectivement j'ai eu envie de voir les fichiers fournis par gtk+-1.x et gtk+-2.x
Mais, la seule commande que je connaisse est : qlist gtk+ qui ne permet pas de spécifier la branche.
Y-aurait-il moyen de savoir quels sont les fichiers installés uniquement par telle ou telle branche ?
