Old-style virtuals are extremely messy and introduce an awful lot of
complexity. They were supposed to be on the way out several years ago,
with GLEP 37, but that seems to have stalled.

Is there anything in particular holding back replacing most or all of
the remaining old-style virtuals with new 'package' virtuals?

There are a few possible issues:

Doing per-profile virtual defaults is a bit messy. If the desired
default for a given subprofile is different, and the 'normal' default
is masked, then || ( ) dependencies are fine. But otherwise you need to
use use flags. That's ok if you can do something like:

    kernel_linux? ( || ( a b c ) )
    !kernel_linux? ( || ( d e f ) )

(being careful to keep the flags outside of the || ( ) because
otherwise crazy stuff happens) but there might not be obvious flags for
certain cases. In the worst case, a new USE_EXPAND_HIDDEN thing could
be introduced to cover it.

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.

There's mention of package.prefer in the GLEP. It's probably not
necessary, thanks to the "if something's already installed, go with
that" behaviour of || ( ) dependencies -- to 'prefer' a provider, you
could just install it first.

However, I strongly suspect that all of these are less of a problem
than the cost of educating developers in all the weird oddities of how
old-style virtuals behave, and how dependencies on old-style virtuals
are nothing like normal dependencies...

Ciaran McCreesh

Attachment: signature.asc
Description: PGP signature

Reply via email to