Bonjour,
je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais
je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du
genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre :
! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le
packet bloquant alors que la version (n+2) de D existe et est stable (en
fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)?
2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
Comme le problème est résolu, c'est pas très grave, mais ça serait
pratique, et je ne comprends pas que la mise à jour n'ai jamais été
proposée.
(pour info,
A = oppenoffice-bin
B = emul-linux-x86-xlibs
C = xorg-x11)
--
gentoo-user-fr@gentoo.org mailing list
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
Yoann Pannier
Pascal BERTIN wrote:
Bonjour, je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre : ! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le packet bloquant alors que la version (n+2) de D existe et est stable (en fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)? 2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
J'imagine que si tu as un paquet E ayant une dépendance du genre "<=package_D_version-n" ou "!>package_D_version-n", portage ne mettra pas à jour package_D.
Ca me semble logique mais ce n'est qu'une vague devination.
Comme le problème est résolu, c'est pas très grave, mais ça serait pratique, et je ne comprends pas que la mise à jour n'ai jamais été proposée.
Quelle a été la résolution manuelle ?
Si c'était de faire un simple emerge -u package_D (sans toucher à un E éventuel) et que ça n'a pas généré d'erreur en disant que E bloquait, mon hypothèse doit être fausse.
(pour info, A = oppenoffice-bin B = emul-linux-x86-xlibs C = xorg-x11)
J'imagine que D == C.
-- Yoann Pannier
-- mailing list
Pascal BERTIN wrote:
Bonjour,
je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais
je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du
genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre :
! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le
packet bloquant alors que la version (n+2) de D existe et est stable (en
fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)?
2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
J'imagine que si tu as un paquet E ayant une dépendance du genre
"<=package_D_version-n" ou "!>package_D_version-n", portage ne mettra
pas à jour package_D.
Ca me semble logique mais ce n'est qu'une vague devination.
Comme le problème est résolu, c'est pas très grave, mais ça serait
pratique, et je ne comprends pas que la mise à jour n'ai jamais été
proposée.
Quelle a été la résolution manuelle ?
Si c'était de faire un simple emerge -u package_D (sans toucher à un E
éventuel) et que ça n'a pas généré d'erreur en disant que E bloquait,
mon hypothèse doit être fausse.
(pour info,
A = oppenoffice-bin
B = emul-linux-x86-xlibs
C = xorg-x11)
Bonjour, je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre : ! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le packet bloquant alors que la version (n+2) de D existe et est stable (en fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)? 2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
J'imagine que si tu as un paquet E ayant une dépendance du genre "<=package_D_version-n" ou "!>package_D_version-n", portage ne mettra pas à jour package_D.
Ca me semble logique mais ce n'est qu'une vague devination.
Comme le problème est résolu, c'est pas très grave, mais ça serait pratique, et je ne comprends pas que la mise à jour n'ai jamais été proposée.
Quelle a été la résolution manuelle ?
Si c'était de faire un simple emerge -u package_D (sans toucher à un E éventuel) et que ça n'a pas généré d'erreur en disant que E bloquait, mon hypothèse doit être fausse.
(pour info, A = oppenoffice-bin B = emul-linux-x86-xlibs C = xorg-x11)
J'imagine que D == C.
-- Yoann Pannier
-- mailing list
Pascal BERTIN
oups, en fait j'ai tout mélangé sur la fin...
A = oppenoffice-bin B = xorg-x11
D = emul-linux-x86-xlibs
la résolution a effectivement été de mettre à jour à la main le package D et je n'ai rencontré aucune erreur.
Yoann Pannier wrote:
Pascal BERTIN wrote:
Bonjour, je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre : ! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le packet bloquant alors que la version (n+2) de D existe et est stable (en fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)? 2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
J'imagine que si tu as un paquet E ayant une dépendance du genre "<=package_D_version-n" ou "!>package_D_version-n", portage ne mettra pas à jour package_D.
Ca me semble logique mais ce n'est qu'une vague devination.
Comme le problème est résolu, c'est pas très grave, mais ça serait pratique, et je ne comprends pas que la mise à jour n'ai jamais été proposée.
Quelle a été la résolution manuelle ?
Si c'était de faire un simple emerge -u package_D (sans toucher à un E éventuel) et que ça n'a pas généré d'erreur en disant que E bloquait, mon hypothèse doit être fausse.
(pour info, A = oppenoffice-bin B = emul-linux-x86-xlibs C = xorg-x11)
J'imagine que D == C.
-- mailing list
oups, en fait j'ai tout mélangé sur la fin...
A = oppenoffice-bin
B = xorg-x11
D = emul-linux-x86-xlibs
la résolution a effectivement été de mettre à jour à la main le package D et je
n'ai rencontré aucune erreur.
Yoann Pannier wrote:
Pascal BERTIN wrote:
Bonjour,
je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais
je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du
genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre :
! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le
packet bloquant alors que la version (n+2) de D existe et est stable (en
fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)?
2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
J'imagine que si tu as un paquet E ayant une dépendance du genre
"<=package_D_version-n" ou "!>package_D_version-n", portage ne mettra
pas à jour package_D.
Ca me semble logique mais ce n'est qu'une vague devination.
Comme le problème est résolu, c'est pas très grave, mais ça serait
pratique, et je ne comprends pas que la mise à jour n'ai jamais été
proposée.
Quelle a été la résolution manuelle ?
Si c'était de faire un simple emerge -u package_D (sans toucher à un E
éventuel) et que ça n'a pas généré d'erreur en disant que E bloquait,
mon hypothèse doit être fausse.
(pour info,
A = oppenoffice-bin
B = emul-linux-x86-xlibs
C = xorg-x11)
la résolution a effectivement été de mettre à jour à la main le package D et je n'ai rencontré aucune erreur.
Yoann Pannier wrote:
Pascal BERTIN wrote:
Bonjour, je n'ai pas vraiment de problème (enfin je l'ai résolu à la main), mais je me pose une question.
je me suis trouvé dans la situation suivante :
soit un package A (installé sur le système) qui a une dependance du genre >=package_D_version-n
soit un autre package B qui est bloqué par quelque chose du genre : ! <= package_D_version-n+2
au moment de mettre à jour B (via -uD), emerge refuse en signalant le packet bloquant alors que la version (n+2) de D existe et est stable (en fait d'autres version plus recentes sont stables aussi)
1) comment se fait-il qu'emerge n'ai jamais mis à jour D (via -uD world)? 2) pourquoi ne le mets-il pas à jour au moment de l'update de B ?
J'imagine que si tu as un paquet E ayant une dépendance du genre "<=package_D_version-n" ou "!>package_D_version-n", portage ne mettra pas à jour package_D.
Ca me semble logique mais ce n'est qu'une vague devination.
Comme le problème est résolu, c'est pas très grave, mais ça serait pratique, et je ne comprends pas que la mise à jour n'ai jamais été proposée.
Quelle a été la résolution manuelle ?
Si c'était de faire un simple emerge -u package_D (sans toucher à un E éventuel) et que ça n'a pas généré d'erreur en disant que E bloquait, mon hypothèse doit être fausse.
(pour info, A = oppenoffice-bin B = emul-linux-x86-xlibs C = xorg-x11)
J'imagine que D == C.
-- mailing list
Yoann Pannier
Pascal BERTIN wrote:
la résolution a effectivement été de mettre à jour à la main le package D et je n'ai rencontré aucune erreur.
Désolé, je crois que ça aurait du marcher tout seul. Et je ne vois pas du tout ce qui a pu faire que ce ne soit pas le cas.
Joker.
-- Yoann Pannier
-- mailing list
Pascal BERTIN wrote:
la résolution a effectivement été de mettre à jour à la main le package D et je
n'ai rencontré aucune erreur.
Désolé, je crois que ça aurait du marcher tout seul. Et je ne vois pas
du tout ce qui a pu faire que ce ne soit pas le cas.
la résolution a effectivement été de mettre à jour à la main le package D et je n'ai rencontré aucune erreur.
Désolé, je crois que ça aurait du marcher tout seul. Et je ne vois pas du tout ce qui a pu faire que ce ne soit pas le cas.
Joker.
-- Yoann Pannier
-- mailing list
Pascal BERTIN
apparemment (Cf http://bugs.gentoo.org/show_bug.cgi?id813), c'est considéré comme normal, il semble que ce soit à l'utilisateur de se débrouiller.
je pense que le problème vient du fait que les deux packages ont été marqués stable (amd64) en même temps, et qu'emerge est 'bloqué' avant de se rendre compte que le paquet en question peut être mis à jour.
Yoann Pannier wrote:
Pascal BERTIN wrote:
la résolution a effectivement été de mettre à jour à la main le package D et je n'ai rencontré aucune erreur.
Désolé, je crois que ça aurait du marcher tout seul. Et je ne vois pas du tout ce qui a pu faire que ce ne soit pas le cas.
Joker.
-- mailing list
apparemment (Cf http://bugs.gentoo.org/show_bug.cgi?id813), c'est considéré
comme normal, il semble que ce soit à l'utilisateur de se débrouiller.
je pense que le problème vient du fait que les deux packages ont été marqués
stable (amd64) en même temps, et qu'emerge est 'bloqué' avant de se rendre
compte que le paquet en question peut être mis à jour.
Yoann Pannier wrote:
Pascal BERTIN wrote:
la résolution a effectivement été de mettre à jour à la main le package D et je
n'ai rencontré aucune erreur.
Désolé, je crois que ça aurait du marcher tout seul. Et je ne vois pas
du tout ce qui a pu faire que ce ne soit pas le cas.
apparemment (Cf http://bugs.gentoo.org/show_bug.cgi?id813), c'est considéré comme normal, il semble que ce soit à l'utilisateur de se débrouiller.
je pense que le problème vient du fait que les deux packages ont été marqués stable (amd64) en même temps, et qu'emerge est 'bloqué' avant de se rendre compte que le paquet en question peut être mis à jour.
Yoann Pannier wrote:
Pascal BERTIN wrote:
la résolution a effectivement été de mettre à jour à la main le package D et je n'ai rencontré aucune erreur.
Désolé, je crois que ça aurait du marcher tout seul. Et je ne vois pas du tout ce qui a pu faire que ce ne soit pas le cas.
