Death to old-style virtuals!
On Sun, Dec 26, 2010 at 05:33:06PM +0200, Petteri RRRty wrote:
> > There's still that stupid !virtual/blah thing to deal with. Old style
> > virtual providers are allowed to block their own virtual to mean "there
> > must not be any other provider of this installed" (although it's not
> > clear what that means if anything other than a simple !virtual/pkg is
> > used). Anything doing that would now have to explicitly list its own
> > blocks. Arguably, this is a good thing, since you'd have to say exactly
> > what you do and don't work with.
> The cases where this is needed could declare the full list of providers
> in an eclass. Are there any problems with this approach besides the
> increased maintenance burden?
Overlay interaction, and the need to bundle a g37 metapkg, allowing it
to get out of date. Adding an "exacly one of" dep spec would be useful
for maintainers also I suspect, and easier on the manager in terms of
processing- it's not required, but advisable in my opinion.
I'm not a fan of old style virtuals, but it also has some benefits
over metapkgs- ease of self blocking is one example, ease of extension
also. There is an additional benefit- it leaves blocking to the
provider. An example would be a provider that unlike all of the
others, can't coexist with them- hasn't been rewritten to eselect or
It might be worth seeing if there is a new form of the decentralized
virtuals we could add w/out the baggage inherited in old style, rather
than just chucking it out in full. Just a thought.
Meanwhile, current old style virtuals still specified in the profiles
Of those, libiconv and opengl have a g37 metapkg.