| Summary: | [PATCH] Add an option to portageq to provide packages that satisfy a virtual | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
| Component: | Core - External Interaction | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | esigra, java |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 155723, 174675, 358927 | ||
| Attachments: |
expand new-style virtuals with `portageq match`
virtuals.py combinations.py combinations.py combinations.py use expand_new_virt function from bug 364673 |
||
|
Description
Petteri Räty (RETIRED)
2006-12-06 11:21:38 UTC
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 virtual/jdk-1.5.0 virtual/jdk-1.4.2 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: dev-java/sun-jdk-1.5.0.10 virtual/jdk-1.5.0 dev-java/blackdown-jdk-1.4.2.03-r12 virtual/jdk-1.4.2 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 virtual/jdk-1.5.0 dev-java/sun-jdk-1.5.0.10 virtual/jdk-1.4.2 dev-java/blackdown-jdk-1.4.2.03-r12 $ portageq match / virtual/jdk:1.5 virtual/jdk-1.5.0 dev-java/sun-jdk-1.5.0.10 $ portageq match / virtual/jre virtual/jre-1.5.0 virtual/jdk-1.5.0 dev-java/sun-jdk-1.5.0.10 virtual/jre-1.4.2 virtual/jdk-1.4.2 dev-java/blackdown-jdk-1.4.2.03-r12 $ portageq match / virtual/jre:1.5 virtual/jre-1.5.0 virtual/jdk-1.5.0 dev-java/sun-jdk-1.5.0.10 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) [edit] > 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]
virtuals.py
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
dev-java/sun-jdk-1.4.2.13-r1
dev-java/sun-jdk-1.5.0.11
dev-java/sun-jdk-1.6.0-r1
betelgeuse@pena ~/python $ java-config -L
The following VMs are available for generation-2:
1) IBM JDK 1.5.0.3 [ibm-jdk-bin-1.5]
2) JamVM 1.4.5 [jamvm]
3) Sun JDK 1.4.2.13 [sun-jdk-1.4]
*) Sun JDK 1.5.0.11 [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]
combinations.py
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.
Example results:
$ ./combinations.py virtual/jre:1.4
dev-java/blackdown-jdk-1.4.2.03-r13
dev-java/kaffe-1.1.7-r5
$ ./combinations.py virtual/jre
dev-java/sun-jdk-1.6.0-r1
dev-java/sun-jdk-1.5.0.11
dev-java/blackdown-jdk-1.4.2.03-r13
dev-java/kaffe-1.1.7-r5
Created attachment 112907 [details]
combinations.py
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]
combinations.py
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 packages. Example input/output: $ portageq expand_virtual / virtual/jre =dev-java/sun-jdk-1.6.0* $ portageq expand_virtual / virtual/jre:1.5 dev-java/gcj-jdk (In reply to comment #14) > Created attachment 274367 [details, diff] > use expand_new_virt function from bug 364673 This is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1edf9e3bd37fede61a21d3b6a84542d29d8f3021 This is fixed in 2.1.10 and 2.2.0_alpha38. |