Re: [gentoo-dev] 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
Re: [gentoo-dev] 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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] 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 signature.asc Description: PGP signature
