Bugzilla Bug 150368

Originally suggested in bug 93469, but here's independent bug.
I think it could be useful to fine-tune version dependency within specified
slot. Syntax could look like ">=cat/foo-1.2.1:1.2" to indicate I want version
1.2.1 or higher, but still within 1.2 slot. That would allow to replace
eclass-based workarounds like "qt_min_version 3.3.3" with
">=x11-libs/qt-3.3.3:3".
Another, generic example is having library foo-1.1, foo-1.2 (both slot 1),
foo-2.0 (slot 2), and package bar-1.1 and bar-1.2. foo-1.1 and bar-1.1 are
stable, 1.2 versions are ~arch. bar-1.2 won't build with foo-1.1 (and of course
not with foo-2.0), it needs something added by foo-1.2. Proposed slot deps
expansion would allow bar-1.2 to depend ">=foo-1.2:1". This way, when user puts
bar-1.2 in his package.keywords, he will be informed to keyword foo-1.2 too,
without having to find out after breakage during emerge.

read bug 143433 comments 6+ for such exact example where this kind of
dependency would really help

There are also some java libs that have SLOT="0" and SLOT="3" for one package
so we may even need to depend on something like ">=cat/foo-1.2.1:0" saying that
we want version with SLOT="0".

Some examples:
dev-java/commons-httpclient
dev-java/commons-lang
dev-java/jaxen

Maybe it would be even more useful if we provided a syntax to group dependency
atoms together, so that a group of atoms produces a single match.  This could
be used for many kinds of version selection, including version ranges.

(In reply to comment #3)
> Maybe it would be even more useful if we provided a syntax to group dependency
> atoms together, so that a group of atoms produces a single match.  This could
> be used for many kinds of version selection, including version ranges.

Then again, we don't need special syntax if we make it implicit as suggested
here: 

https://bugs.gentoo.org/show_bug.cgi?id=4315#c13

I'm not completely sure if that will work for all possible use cases, but maybe
it will.

It's pretty clear that we'll have some extension of the dep syntax sometime in
the future.  The next step seems to be some type of syntax to group
restrictions together, which is the spirit of bug 4315.  It will probably
require a GLEP.

*** This bug has been marked as a duplicate of 4315 ***

This bug seems to be fixed in Portage 2.1.2.

Yes, it mostly works in 2.1.2.  There are some fixes in 2.1.2.9 that make it
work better though.

Please reopen if there's anything about 2.1.2.9 that doesn't work properly for
this bug.

Hm is it mentioned anywhere in news, changelog etc? The syntax I mean.

Current slot deps support differs from previous atom syntax in only the :slot
suffix.  Other than that extension, dep atom syntax is identical to how it was
before slot deps.  The slot simply adds an extra constraint on which packages
can be matched.  I think that this behavior is intuitive to most people.  It
still needs to be documented, but it's not going to be usable in ebuilds until
we do an EAPI-1 bump (should be sometime during the next few months).