For ebuilds with DEPEND of the form: >=category/package-0.3.5:= <category/package-0.4.0_alpha Assume category/package has SLOT="${PV}/${PR}". If there are multiple versions of category/package installed (e.g. 0.3.5 and 0.4.1), the binary package will have the following in its DEPEND metadata: >=category/package-0.3.5:0.4.1 <category/package-0.4.0_alpha This is not what actually is needed for category/package and not what portage actually uses to fulfill the dependency. The workaround I found is to move the slot operator to the upper bound i.e. >=category/package-0.3.5 <category/package-0.4.0_alpha:= which yields the expected result in the binary package: >=category/package-0.3.5 <category/package-0.4.0_alpha:0.3.5 This appears to be related to the depgraph output assigning matches to both bounds even though only one match is used during an actual emerge. See also: https://bugs.gentoo.org/4315
(In reply to Allen Webb from comment #0) > For ebuilds with DEPEND of the form: > > >=category/package-0.3.5:= <category/package-0.4.0_alpha > > Assume category/package has SLOT="${PV}/${PR}". If there are multiple > versions of category/package installed (e.g. 0.3.5 and 0.4.1), the binary > package will have the following in its DEPEND metadata: > > >=category/package-0.3.5:0.4.1 <category/package-0.4.0_alpha This is correct behavior for such multiple elements in *DEPEND. A single element using version range (not yet implemented feature discussed in aforementioned bug) would probably have different behavior. > The workaround I found This is not workaround, but currently the only proper solution for what you want to achieve. > This appears to be related to the depgraph output assigning matches to both > bounds even though only one match is used during an actual emerge. It is not impossible for one package to use multiple slots of another package. There have been several cases of some packages depending on both Python 2.7 and 3.*.
