Bug 74877 – When a virtual-X dep is encountered that is not fulfilled, give user a choice.

• Product: Portage Development
• Status: RESOLVED WONTFIX

[Description Alec Warner (RETIRED) 2004-12-18 13:10:52 UTC]

When emerge encounters a virtual dep that isn't filled, right now it just pulls in the default package.  Instead of this, give the user a choice of packages that satisfy virtual-X and let them pick the one they want, or press something else to just use a default one.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




I talked to ferringb about this a bit.  He suggested using a new ebuild class 
that is just for virtuals.  Basically you have an ebuild for the virtual class ( 
lets say X for example).  virtual-x11.ebuild.  Inside that ebuild you have a 
list of all the packages that satisfy the virtual-x11 dependency.  Then you just 
check if one of the satisfying packages and it's dependencies are installed.  If 
they are, then virtual-x11 is satisfied and nothing new will happen.  However, 
if it is not satisfied, the user is presented with a choice of packages.  They 
pick which one they want, and portage adds it to the dep tree to be emerged.

The only problem I can see with this is people not knowing what some of the 
virtuals are ( virtual-mta ) for example.  In this case this behavior could be 
enabled by a FREATURES flag or the new ebuild class could specify one of the 
packages as a default ( this behavior is really specified right now, as there 
are virtual defaults currently ).  That way if they have no clue what any of the 
packages are, the user can just say "default" and get it done with.

[Comment 1 Marius Mauch (RETIRED) 2004-12-22 16:26:17 UTC]

For some reason I can't specify I don't like this ...

[Comment 2 Alec Warner (RETIRED) 2004-12-27 11:48:02 UTC]

Another suggestion that was brought up was to add a PROVIDE scanner to equery.  That way when something deps on virtual-foo someone can do a equery --provider virtual-foo and get a list of providers.  Then they can choose to emerge a provider and then continue on with whatever depended on virtual-foo.

Not nearly as integrated.  However having a tool like this available is IMHO a good thing.  Sometimes the gentoo default providers aren't my cup of tea (personally) but god knows i can't list all the providers for virtuals, or even know what every virtual means.  This is also a bit easier to implement, although it's a costly operation to do.

[Comment 3 Marius Mauch (RETIRED) 2004-12-27 11:50:48 UTC]

Gah, realized that you'd have to maintain virtuals in two places (or break compability), bad idea. The actual need is a PROVIDE scanner (or more general: a metadata/aux_get scanner) which is IMO much more useful as it doesn't depend on this specific scenario.