FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 12-17-2010, 05:08 PM
Ciaran McCreesh
 
Default Death to old-style virtuals!

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
 
Old 12-26-2010, 02:33 PM
Petteri Räty
 
Default Death to old-style virtuals!

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
 
Old 12-30-2010, 01:51 PM
Brian Harring
 
Default 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
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
 

Thread Tools




All times are GMT. The time now is 06:13 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org