According to emerge (1): /var/cache/edb/virtuals Contains a list of packages used to resolve virtual dependen- cies. In the case of failing virtual matches, you may reorder the entries for the corresponding virtual here. The first pack- age listed after the virtual is the entry used for matching the virtual. However the effect of settings.getvirtuals() (in current viewcvs) is to reverse the order of virtual candidates from each virtual source (tree, user, profile) - see ll 1731-1733 in pym/portage.py. Thus it is actually the last package on the line after a particular virtual that is favoured in matching that virtual. 1. To preserve documented semantics and also preserve incremental stacking (deletion with '-') it would be necessary to reverse the order of virtual candidates going into stack_dictlist: --- pym/portage.py 2004/04/28 03:03:42 1.1 +++ pym/portage.py 2004/04/28 03:27:20 @@ -1728,6 +1728,9 @@ class config: #dirVirtuals = stack_dicts(dvirts, incremental=1) #dirVirtuals = grab_stacked("virtuals",myvirtdirs,grabdict) # User settings and profile settings take precedence over tree. + for x in dirVirtuals+[treeVirtuals]+[userVirtuals]: + for y in x.keys(): + x[y].reverse() val = stack_dictlist(dirVirtuals+[treeVirtuals]+[userVirtuals],incremental=1) for x in val.keys(): val[x].reverse() 2. Alternatively stack_dictlist should be modified to place order stackings such that items from later dictionaries appear earlier in values in the result; this is somewhat counter-intuitive. 3. Alternatively stack_dictlist should be modified so that it is earlier dictionaries that take precedence. This fits better with the Portage dependency resolution model that earlier tokens in a || ( ) list take precedence, and would require little propagation of changes as stack_dictlist is used in relatively few places in current code. 4. Alternatively the man page (and any other docs) should be modified to state that the last candidate on a virtual line takes precedence.
*** This bug has been marked as a duplicate of 45468 ***
Reopening. This is not a duplicate of bug 45468; it is a regression (with portage-2.0.51_pre7 and in CVS HEAD). Demonstration: ed@capella ed $ grep opengl /etc/portage/virtuals /etc/make.profile/virtuals /etc/portage/virtuals:virtual/opengl media-video/nvidia-glx x11-base/xorg-x11 /etc/make.profile/virtuals:virtual/opengl x11-base/xfree ed@capella ed $ PATH=/usr/lib/portage/pym:$PATH python Python 2.3.3 (#1, Apr 17 2004, 03:17:09) [GCC 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from portage import * >>> settings.getvirtuals("/")['virtual/opengl'] ['x11-base/xorg-x11', 'media-video/nvidia-glx', 'x11-base/xfree'] >>>
Fixed in CVS. >=portage-2.0.51_pre9
2.0.51_pre13 is out, afaik this was limited to strictly pre7 (and corrected in pre8). Closing, reopen if it rears its head again.
