Summary: | Virtuals discovered prior to dep checking are not verified against the dep graph | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | csights |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sascha-gentoo-bugzilla, SebastianLuther, x11 |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 270496, 288499 |
Description
csights
2005-02-18 11:46:54 UTC
*** This bug has been marked as a duplicate of 1343 *** Marius, that's a different bug... ode-0.5-r2: DEPEND="virtual/opengl" base/virtuals: virtual/opengl x11-base/xorg-x11 xorg-x11-6.8.0-r4: PROVIDE="opengl? virtual/opengl" 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 A 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. |