Bug 424123 – xcb-util-0.3.9 => 0.3.8 downgrade cannot happen due to SLOT conflicts and file collisions from xcb-util-*-0.3.9

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Ian Stakenvicius (RETIRED) 2012-06-29 15:01:47 UTC]

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)

[Comment 1 Chí-Thanh Christopher Nguyễn 2012-07-03 20:30:20 UTC]

I don't see anything wrong with the dependencies. Could this be a limitation of the package manager maybe?

[Comment 2 Ian Stakenvicius (RETIRED) 2012-07-03 20:45:57 UTC]

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.

[Comment 3 Zac Medico 2012-07-03 20:50:40 UTC]

(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.

[Comment 4 Matt Turner 2015-09-06 16:49:58 UTC]

xcb-util-0.3.8 is no longer in the tree. I'm guessing this is a WONTFIX/OBSOLETE?