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.
For some reason I can't specify I don't like this ...
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.
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.
