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
Description: PGP signature