I am having a problem with virtual dependencies being ignored. The package dev-games/ode requires virtual/opengl which is provided by x11-base/xorg-x11 _when compiled with USE="opengl"_. (ODE correctly reports its virtual dependency in the its ebuild.)
Steps to Reproduce:
1.USE="-opengl -xv" emerge xorg-x11 ode
emerge "says" that nothing is wrong and tries to emerge xorg-x11 and ODE:
#USE="-opengl -xv" emerge -av xorg-x11 ode
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] x11-base/xorg-x11-6.8.0-r4 -3dfx +3dnow +bitmap-fonts -cjk
-debug -dlloader -dmx -doc +font-server -hardened -insecure-drivers -ipv6
-minimal +mmx +nls -opengl* +pam -sdk -sse -static +truetype-fonts +type1-fonts
(-uclibc)-xprint -xv* 0 kB
[ebuild N ] dev-games/ode-0.5-r2 -doc 0 kB
ODE fails to compile because of missing header files (GL/gl.h and others)
emerge should at least give some kind of warning about "failed virtual dependencies"
#emerge -av xorg-x11 ode
does compile correctly (because I have opengl and xv set in make.conf)
Gentoo Base System version 1.4.16
Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5, glibc-220.127.116.1140808-r1
, 2.4.24-om2 i686)
System uname: 2.4.24-om2 i686 AMD Athlon(tm) Processor
Python: dev-lang/python-2.3.4-r1,dev-lang/python-2.2.3-r5 [2.3.4 (#
1, Feb 14 2005, 20:17:21)]
ccache version 2.3 [enabled]
dev-lang/python: 2.3.4-r1, 2.2.3-r5
sys-devel/autoconf: 2.13, 2.59-r6
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.4
virtual/os-headers: 2.4.19-r1, 2.4.21-r1
CFLAGS=" -march=athlon -O2 -pipe"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X1
1/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/
config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS=" -march=athlon -O2 -pipe"
FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks sandbox sfperms"
o http://gentoo.chem.wisc.edu/gentoo/ http://gentoo.mirrors.pair.com/"
USE="x86 3dnow X apm avi berkdb bitmap-fonts crypt cups fam font-server gdbm gif
gtk2 imagemagick jpeg libg++ mmx motif mpeg nls oggvorbis opengl pam png python
quicktime readline real ssl tetex tiff truetype truetype-fonts type1-fonts xv z
Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
*** This bug has been marked as a duplicate of 1343 ***
Marius, that's a different bug...
There's actually two bugs here that will result in the same symptom. base/virtuals needs to use a (not-yet usable) USE-based dep, and the installed version of xorg-x11 that does provide the virtual is about to be reinstalled with one that doesn't. The latter problem should be fixable in 2.0.51.
x11 people, what other providers of virtual/opengl are there? Would it be possible to change the default to something that's not USE-based for the time being?
There used to be xfree and a separate mesa build, and there will probably be a separate mesa build again in the future. It's still in the tree but it's way old.
It would be possible to change it to a non-USE-based provide, but it would be wrong when X is built without USE=opengl. It would be as if X just decided to provide virtual/mta, virtual/alsa or whatever else.
Fair enough - so nothing can be done from the other side.
This is easily fixed by using portdb.aux_get() to check PROVIDE inside portage._expand_new_virtuals(). The the USE conditionals are automatically evaluated since portdb in this scope is really and instance of depgraph._dep_check_composite_db which instantiates Package instances and evaluates their USE appropriately. The spot to change looks like this:
# Plain old-style virtuals. New-style virtuals are preferred.
for y in mychoices:
a.append(portage.dep.Atom(x.replace(mykey, y, 1)))
Before appending the atom there, first use portdb.match() with the atom, use portdb.aux_get() to get the PROVIDE, and check that the relevant virtual is contained in PROVIDE (it can contain multiple values, so split it first).
This is fixed in svn r13742.
The case where you install the provider and the consumer at once is solved now, but what about this:
A dpenends on virtual/xy
B has PROVIDE="useflag? ( virtual/xy )"
a) Install B with "useflag" enabled.
b) Install A
c) Re-install B with "useflag" disabled.
This works atm and leaves A broken.
and one more problem: after doing steps a-c from the last comment:
emerge: there are no ebuilds to satisfy "virtual/xy".
(dependency required by "dev-libs/A-1.0" [ebuild])
(dependency required by "A" [argument])
It leaves the user with no information about how to solve the problem.
Currently the following happens:
1) Read the PROVIDE from ebuild.
2) Use use_reduce to simplify PROVIDE and decide if the package actually provides something. Leaving no indication that it provides/does not provide a virtual if you change a useflag.
What about the following?
2) Convert PROVIDE="useflag? ( virtual/xy )" from package cat/pkg-v to virtual/xy: cat/pkg-v[useflag].
Doing this would expand virtual/xy later on to cat/pkg-v[useflag] instead of either nothing or cat/pkg-v, giving the user the information to fix it.
(In reply to comment #7)
> c) Re-install B with "useflag" disabled.
I'm planning to enable --complete-graph by default, and then it will bail out if they try to do that.
(In reply to comment #8)
> What about the following?
> 2) Convert PROVIDE="useflag? ( virtual/xy )" from package cat/pkg-v to
> virtual/xy: cat/pkg-v[useflag].
> Doing this would expand virtual/xy later on to cat/pkg-v[useflag] instead of
> either nothing or cat/pkg-v, giving the user the information to fix it.
Seems a little convoluted. Why not just use a new-style virtual containing a USE dep? I guess you sort of want to generate a new-style virtual from an old-style virtual. I guess that's fine, but I'd encourage people to just use new-style virtuals instead.
This is fixed in 2.2_rc34.
This is fixed in 2.1.7.