Bugzilla Bug 93469

Imho, it would makes things sometimes easier if it would be possible to depend
directly on slots instead of package versions. we make often use of the
slotting idea for java packages since the java programmers tend to break their
api even in minor version bumps. sometimes there are versions which are fully
api compatible, which should be in the same slot, like version 1 and version 2.
for such a situation it would be nice if it would be possible to add a
depend/rdepend like: 

DEPEND="%foobar-1" , where 1 means slot 1. the '%' is just an idea for an token
that could be used to indicate that we depend on a slot instead of the package
version. java-config already supports something like that for getting the
classpath of installed packages, like 'java-config --classpath=xerces-2' where
xerces is the package name an 2 the slot. what do you think?

The syntax that has been thrown about for a while is cat/pkg:slot. However  
dynamic slots will also be required. Still trying to figure out if it's even  
possible for the ability to dynamically depend on a dynamic slot is possible. 
So.. That's a "maybe". 

Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 

USE based slots for chost and such would certainly be nice too though (so that,
for example, crossdev wouldn't have to do it's package name mangling trick). 
If anyone needs a primer on various types of slots, I've found this email
useful:

http://article.gmane.org/gmane.linux.gentoo.devel/20153

Maybe we should just focus on static slots for now, since that's all that
portage currently supports anyway? Paludis apparently supports
cat/pkg:slot::repo[use] syntax.

Adding java@g.o since we love using SLOTs :)

Interested in this as it could be a better/alternate solution to ranged
dependencies (bug 4315)

I think it would be nice if there was a way to fine-tune wanted version inside
the slot, like >=cat/foo-1.2.1-r2:1.2 in case -r2 fixes something the depending
package needs to build against it.

*** Bug 143111 has been marked as a duplicate of this bug. ***

In svn r4594 I have added support for slot based dep matching in all dbapi
derived classes.  The supported syntax is ${CATEGORY}/${PN}:${SLOT} (identical
to that used by paludis and pkgcore).  It may still be necessary to add support
in some other areas such as the best_match_to_list function and the global
updates code (config files, slot moves, etc...).  The existing support is
enough to allow one to use slot based deps on the emerge command line.  It's
also enough to allow me to fix bug 4698 with a little work.

So it's not possible what comment 6 suggests?

(In reply to comment #6)
> I think it would be nice if there was a way to fine-tune wanted version inside
> the slot, like >=cat/foo-1.2.1-r2:1.2 in case -r2 fixes something the depending
> package needs to build against it.

That would be significantly more work to implement.  The
${CATEGORY}/${PN}:${SLOT} style turned out to be much easier to implement than
I had initially expected.

I've added support for global updates slotmoves in svn r4597 and
best_match_to_list() is svn r4598.  I think that completes support for slot
deps (aside from the additional behavior suggested in comment #6).

This has been released in 2.1.2_pre2-r4.

Request from comment 6 moved to bug 150368, for anyone interested.