We have same java packages that provide the same API. We would like to choose from these package at merge time. Currently we hard code in implementation. If portageq provides the necessary information, our eclasses can do the rest with prioritising and all.
Details/usage examples might help (porttree vs. vdb, old-stlye vs. new-stlye virtuals, ...)
Maybe we can extend the portageq "match" function so that it does what you want.
Here's an example of current behavior:
$ portageq match / virtual/jdk
If we make it do a call to portage.dep_check(), and then match the results against installed package, you you get something like this instead:
Would satisfy your needs?
Created attachment 103508 [details, diff]
expand new-style virtuals with `portageq match`
This implements expansion of new-style virtuals as described in Comment #2. Here are some samples of the output:
$ portageq match / virtual/jdk
$ portageq match / virtual/jdk:1.5
$ portageq match / virtual/jre
$ portageq match / virtual/jre:1.5
Just so that we don't change the old "match" behavior too much, I suppose we could call this one "expand_match" or something. The only way that it should deviate from old "match" behavior is in the expansion of new-style virtuals.
(In reply to comment #3)
> Created an attachment (id=103508) 
> expand new-style virtuals with `portageq match`
> This implements expansion of new-style virtuals as described in Comment #2.
> Here are some samples of the output:
Looks like I should be able to make it work with this. There's no hurry to commit this stuff until we have something working so the code is tested in practice.
Any reason why this code should be in portageq instead of dbapi? IMO portageq should be just an API wrapper and not implement additional logic itself.
(In reply to comment #6)
> Any reason why this code should be in portageq instead of dbapi? IMO portageq
> should be just an API wrapper and not implement additional logic itself.
I think it's fine if we make this part of the api but I don't think we should embed it into the dbapi classes. Actually, the new portageq function that I've implemented is mostly just a wrapper around portage.dep_check() but it has a little bit of greed atoms logic too so that it behaves more like the original match function. I think of the dbapi classes as simple package databases and I don't think logic for higher level conceptual things like virtuals should be embedded in them. The dbapi.match() functions do support expansion of old-style viruals, but I think that was a mistake. That feature isn't even used by portage internals, since both old and new-style virtuals are expanded internally by portage.dep_check().
The patch does not apply to ~x86 portage any more.
Created attachment 112401 [details]
Ok. I started experimenting with this as an individual program and it does not do what I need:
betelgeuse@pena ~/python $ python virtual.py / virtual/jdk
betelgeuse@pena ~/python $ java-config -L
The following VMs are available for generation-2:
1) IBM JDK 22.214.171.124 [ibm-jdk-bin-1.5]
2) JamVM 1.4.5 [jamvm]
3) Sun JDK 126.96.36.199 [sun-jdk-1.4]
*) Sun JDK 188.8.131.52 [sun-jdk-1.5]
5) Sun JDK 1.6.0 [sun-jdk-1.6]
There should be ibm-jdk-bin-1.5 in the output (jamvm is just a virtual/jre). I want this to list every possible thing that matches the rules.
Unfortunately the current behavior of the dep_check() function will not satisfy your needs since it does not support greedy matching internally. It's only designed to select a single combination of atoms, while you want all possible combinations. I'll work on a version of virtuals.py that returns all possible combinations.
Created attachment 112894 [details, diff]
This script will show all possible combinations of installed packages that satisfy a given dependency string. I know this is a lot of code for what seems like a simple task. In the future the portage api should include features that make a task like this much simpler.
$ ./combinations.py virtual/jre:1.4
$ ./combinations.py virtual/jre
Created attachment 112907 [details]
This version fixes a bug in the combinations logic and adds a --test option to verify that various depstrings produce the correct number of combinations.
Created attachment 115387 [details]
This version shows slot atoms instead of specific versions.
Created attachment 274367 [details, diff]
use expand_new_virt function from bug 364673
Since bug 364673, there's an expand_new_virt() function that may be useful here. This patch uses the function to expand virtual atoms to non-virtual atoms as follows:
portageq expand_virtual <root> <atom>
Returns a \n separated list of atoms expanded from a
given virtual atom, excluding blocker atoms. Satisfied
virtual atoms are not included in the output, since
they are expanded to real atoms which are displayed.
Unsatisfied virtual atoms are displayed without
any expansion. The "match" command can be used to
resolve the returned atoms to specific installed
$ portageq expand_virtual / virtual/jre
$ portageq expand_virtual / virtual/jre:1.5
(In reply to comment #14)
> Created attachment 274367 [details, diff]
> use expand_new_virt function from bug 364673
This is in git now:
This is fixed in 2.1.10 and 2.2.0_alpha38.