The subslot in libxcb-1.11.1 is defined as ${PV}, however I strongly doubt that the ABI changed between 1.11 and 1.11.1 so this definition just cause annoying blockers and rebuilds over the place.
Example: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: x11-libs/libxcb:0 (x11-libs/libxcb-1.11.1:0/1.11.1::gentoo, ebuild scheduled for merge) pulled in by x11-libs/libxcb (Argument) (x11-libs/libxcb-1.11-r1:0/1.11::gentoo, installed) pulled in by >=x11-libs/libxcb-1.9.3:0/1.11=[abi_x86_32(-),abi_x86_64(-)] required by (media-libs/mesa-10.3.7-r1:0/0::gentoo, installed)
It appears that it was introduced here: https://gitweb.gentoo.org/proj/x11.git/commit/?id=b5780ff818efc06a5d6861f29905aab064550182 Could we please either get some information about the purpose of this subslot or remove it?
CC'ing committer so he can explain
(In reply to Chí-Thanh Christopher Nguyễn from comment #3) > CC'ing committer so he can explain Any update on this?
Can we please finally fix this? libxcb-1.12 becoming a new stable and still has this problem.
with 1.12 already stable by now, I've now hardcoded 0/1.12 subslot to avoid further damage until we see it actually needs a subslot bump upon e.g 1.13 release. This is a revbump because I reverted -r1 and didn't wan't ~arch users to see a downgrade from -r1 to -r0, plus -r0 was already stable, even though the resulting metadata should be the same as $PV is 1.12. Leaving bug open for further discussions on whether we should have a subslot at all anymore (and so subslot operator deps on libxcb at higher levels), if we should maybe make it 0/$(get_version_component_range 1-2) already, etc.
(In reply to Mart Raudsepp from comment #6) > with 1.12 already stable by now, I've now hardcoded 0/1.12 subslot to avoid > further damage until we see it actually needs a subslot bump upon e.g 1.13 > release. > This is a revbump because I reverted -r1 and didn't wan't ~arch users to see > a downgrade from -r1 to -r0, plus -r0 was already stable, even though the > resulting metadata should be the same as $PV is 1.12. > > Leaving bug open for further discussions on whether we should have a subslot > at all anymore (and so subslot operator deps on libxcb at higher levels), if > we should maybe make it 0/$(get_version_component_range 1-2) already, etc. If ABI breaks and it requires rebuild it should have a specific subslot, thats fine. But subslot should only be updated when ABI is not compatible, so unless it is documented to break on specific parts of the version tuple (e.g major version bump), it should be updated manually
libxcb-1.13 was released with the same ABI as 1.12, so leaving this as SLOT="0/1.12" is the right thing to do.
