> 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
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.
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"