public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Feature Request/RFC : "Elective" virtuals
Date: Sat, 30 Jun 2012 05:33:21 +1200	[thread overview]
Message-ID: <CAATnKFCj-7WJoev4A2jnviaBWZSqbUU6qKU5Huei_-N0xDx2Gg@mail.gmail.com> (raw)
In-Reply-To: <4FED9FF3.6060302@gentoo.org>

>
> 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



      reply	other threads:[~2012-06-29 17:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-29  1:41 [gentoo-dev] Feature Request/RFC : "Elective" virtuals Kent Fredric
2012-06-29 12:30 ` Ian Stakenvicius
2012-06-29 17:33   ` Kent Fredric [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAATnKFCj-7WJoev4A2jnviaBWZSqbUU6qKU5Huei_-N0xDx2Gg@mail.gmail.com \
    --to=kentfredric@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox