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.
