I tried to update pygtk with `emerge -uvp --oneshot pygtk` with portage-2.1.2_rc3-r5, but here is the result: Calculating dependencies... done! [blocks B ] <dev-python/pygtk-2.9 (is blocking dev-python/pygobject-2.12.3) [ebuild U ] x11-libs/pango-1.14.9 [1.14.7] USE="-debug -doc" 1,263 kB [ebuild U ] media-libs/mesa-6.5.1-r4 [6.5.1-r2] USE="motif nptl -debug -doc -hardened -xcb" VIDEO_CARDS="radeon -i810 -mach64 -mga -none -r128 -s3virge -savage -sis (-sunffb) -tdfx -trident -via" 0 kB [ebuild U ] dev-libs/atk-1.12.3 [1.12.1] USE="-debug -doc" 646 kB [ebuild U ] gnome-base/libglade-2.6.0 [2.5.1] USE="-debug -doc" 312 kB [ebuild U ] dev-python/pygtk-2.10.3 [2.8.6] USE="opengl -doc" 1,932 kB [ebuild N ] dev-python/pygobject-2.12.3 USE="-debug -doc" 332 kB So it seems that newly installed pygobject (dependency of pygtk-2.10.3) blocks update of pygtk-2.8.6 (that has no dependency on pygobject). Output `emerge -uvp --oneshot --debug pygtk` attached.
Created attachment 104120 [details] Output of `emerge -uvpt --oneshot --debug pygtk`
Not a portage bug...
And not a bug at all, the blocker is needed. *** This bug has been marked as a duplicate of 157394 ***
(In reply to comment #2) > Not a portage bug... Sorry, but I think that this is a problem of portage. The pygobject dependency should start blocking as soon as pygtk-2.10.3 is updated (so it should not block). Now it starts blocking before the update is actually done. Portage should take into account the actual order of installing packages for calculating dependencies. So this is a bug, or at least a feature request (please decide). Blockers can be removed after the installation order of packages is known, or the sequence could be tuned up to fulfil all dependencies. Whenever you say that `emerge -C package && emerge package` fixes the problem, then there is some real problem of emerge. That is something like: switching the computer off and on will fix software freezes of your Windows machine :-)
No, the blocker is intended and work as needed to prevent collisions.
(In reply to comment #5) > No, the blocker is intended and work as needed to prevent collisions. This is the way how it works now, but I think this is not the correct way how it should work. I really do not want to argue and reopen bug again and again, so please explain me the _real_ reasons of the collision here (in this particular case). There is an update of pygtk that installs new pygobject. The sequence of operations should be (the same is shown in the output of emerge): 1. pygtk update 2. installation of pygobject (dependency of NEW pygtk) I do not see conflict with any other package in the system. I really think that this is the way, how it should work. Pygobject cannot live without >=pygtk-2.10, but it will have it! This is the last time I reopened the bug. If you still think that this is not the right think the portage should do, you can close it and I will stop screaming.
Fixing this "bug" would cause collisions between those packages on upgrade. Please, stop reopening this bug without doing any research whatsoever on why the blocker is in place.
Closed, nothing to fix here.
(In reply to comment #6) > I really do not want to argue and reopen bug again and again, so please > explain me the _real_ reasons of the collision here (in this particular > case). > > There is an update of pygtk that installs new pygobject. The sequence of > operations should be (the same is shown in the output of emerge): > > 1. pygtk update > 2. installation of pygobject (dependency of NEW pygtk) The problem is that the new version of pygtk depend on pygobject. That means it cannot be upgraded before pygobject has been installed. But installing pygobject before the old version of pygtk has been removed results in collisions. Policy dictates that portage cannot just remove packages without the user knowing it. Hence a blocker is the only option that is left..
