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