xcb-util-0.3.8 has '>=' PDEPENDS on xcb-util-image , xcb-util-wm, etc. The 0.3.9 versions of all of these packages *DEPEND on xcb-util-0.3.9. This automatically forces a slot conflict as the -0.3.9 versions will always be brought in by emerge (due to having the same keywords), even if they are --unmerge'd first. xcb-util-0.3.8 should have = or ~ based atoms on its PDEPENDs Furthermore, it is possible that xcb-util-0.3.8 needs a !> RDEPEND on each of these PDEPENDs so that file collisions are avoided (this part is unconfirmed)
I don't see anything wrong with the dependencies. Could this be a limitation of the package manager maybe?
I'll detail it out: xcb-util-0.3.8 PDEPENDs on >=xcb-util-image-0.3.8 This is satisfied by xcb-util-image-0.3.8 and xcb-util-image-0.3.9. xcb-util-image-0.3.9 RDEPENDs on >=xcb-util-0.3.9 *SO*, if you mask xcb-util-0.3.9 and try to re-emerge, you get xcb-util-0.3.8 bringing in xcb-util-image-0.3.9 which needs xcb-util-0.3.9 and so they conflict on SLOT=0. If xcb-util-0.3.9 _and_ xcb-util-*-0.3.9 are masked, then things work as expected, but a simple PDEPEND change (as mentioned above) on 0.3.8 to reflect the actual truth (which is that xcb-util-0.3.8 cannot PDEPEND on xcb-util-*-0.3.9 or above), then portage cab resolve this on its own.
(In reply to comment #1) > I don't see anything wrong with the dependencies. There's nothing wrong with them except that they're likely to trigger conflicts that require the dependency resolver to do lots of backtracking if the user tries to downgrade from xcb-util-0.3.9 to xcb-util-0.3.8. > Could this be a limitation of the package manager maybe? It's possible that a large emerge --backtrack setting could solve the conflict automatically. Alternatively, the user can recognize the source of conflict and mask the xcb-*-0.3.9 packages if they really want to use xcb-util-0.3.8.
xcb-util-0.3.8 is no longer in the tree. I'm guessing this is a WONTFIX/OBSOLETE?
