> > Perhaps it would be best to tell users that if they'd like to see the > possible choices they can run ie 'qdepends -r virtual/cron' >
Quite, perhaps it could be a seperate mechanism, it would just seem that for virtuals that just provide a list of alternatives, having a seperate package that gives the *choice* of one of those alternatives seems like redundant code. ( Most virtuals are simple non-exclusive ors, so the packages that satisfy them can all be installed simultaneously, however, there are a few virtuals that are inherently exclusive-ors, as all the dependents exclude each other ) Perhaps it could be an additional metafield, upon which the choice of one of several choices could be presented to the user by using a different tool. All packages which have an "alternatives" mechanism like this could then also be indexed and the user could then only enter the selection process with a separate tool which is a wrapper for portage. I'm not sure if it makes sense or not to make it as an eselect submodule that lets the user make choices and then have something else apply them, or a dedicated tool; ie: eselect alternatives list # list all the "things" that have dependents that are mutually exclusive choices eselect alternatives set cron --auto # selects vixie-cron eselect alternatives set cron cronie emerge -uvatDN @changed_alternatives Or something like that. You could drive it of course using external metadata not bundled with the virtual's themselves, the benefit being you avoid the need to trip the whole change process for virtuals and stabilisation, but the downside is of course possible desynchronisation of choice metadata with choices that are available via the virtual. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
