[gentoo-dev] Death to old-style virtuals!

[gentoo-dev] Death to old-style virtuals!

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Old-style virtuals blocking feature needed for virtual/mta

[Torsten Veller]

* Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> Is there anything in particular holding back replacing most or all of
> the remaining old-style virtuals with new 'package' virtuals?

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

This is a problem for virtual/mta.

As long as we have to block all other mailers with the sendmail
compatibility interface to avoid collisions, adding explicit blockers
for mailers in all repositories is unlikely to work well.

The former mailwrapper/mailer-config tools solved this problem but they
were too slow. Once we have a better alternatives system (#348843) the
problem might be sorted out (as you probably know).

-- 
Regards Torsten

Re: [gentoo-dev] Death to old-style virtuals!

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On 12/17/2010 08:08 PM, Ciaran McCreesh wrote:
> 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?
> 

I would create a tracker bug for getting rid of the old style things.
Then perhaps EAPI 5 could not support old style virtuals.

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

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Death to old-style virtuals!

[Brian Harring]

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 
something equivalent.

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

virtual/alsa
virtual/antivirus
virtual/aspell-dict
virtual/baselayout
virtual/blackbox
virtual/bootloader
virtual/cron
virtual/dev-manager
virtual/dhcpc
virtual/dhcpcd
virtual/fam
virtual/gzip
virtual/imap-c-client
virtual/imapUW
virtual/imapd
virtual/inetd
virtual/j2ee
virtual/jabber-server
virtual/krb5
virtual/libc
virtual/libiconv
virtual/libpcap
virtual/linux-sources
virtual/logger
virtual/lpr
virtual/m3
virtual/mailx
virtual/man
virtual/mda
virtual/modutils
virtual/mta
virtual/ooo
virtual/opengl
virtual/os-headers
virtual/pam
virtual/pbs
virtual/php
virtual/portage
virtual/python
virtual/quicktime
virtual/ruby
virtual/skkserv
virtual/squeak-image
virtual/ssh
virtual/tftp
virtual/utempter
virtual/w3m
virtual/wine

Of those, libiconv and opengl have a g37 metapkg.

~harring