Dnia 2014-07-28, o godz. 13:02:39
Ian Stakenvicius <a...@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 28/07/14 07:21 AM, Michał Górny wrote:
> > Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius <a...@gentoo.org>
> > napisał(a):
> > 
> >> Hey all..  So, putting aside for now how much of a mess this
> >> would be to implement in the virtuals' ebuilds themselves, what
> >> do people think of changing the virtuals so that they contain an
> >> entry in IUSE for each provider that can satisfy it?
> >> 
> >> The idea here is that the package satisfying a virtual could be 
> >> optionally explicitly-chosen through package.use (or USE= in 
> >> make.conf, perhaps) instead of having an entry in @world, that
> >> way if nothing depends on the virtual then it and the provider
> >> can be - --depclean'ed from the system.  The idea is specifically
> >> NOT to have rdeps depend on these flags, that would undermine the
> >> whole purpose of the virtual; it would just be for end-users to
> >> set if they so chose.
> > 
> > I think I don't get this argument.
> > 
> > If you really want to have a particular provider for the virtual
> > for external purposes, it's fully purposeful to put it in @world
> > or otherwise in a custom set. In this case, USE flags aren't
> > helpful.
> 
> The argument I was trying to make is that USE flags would allow
> end-users to accomplish the same thing, while not having an entry in
> @world and therefore allowing the package to be --depclean'ed if the
> virtual is --depcleaned.

If you need it externally, you need it not depcleaned, obviously. So
you have to have something in @world. If you need a specific
implementation, it's more elegant to put that in @world rather than
the virtual and playing with USE flags.

> > If you only prefer a particular provider, you can tip portage
> > easily to use it without resorting to USE flags. This also allows
> > portage to semi-transparently switch to other provider if
> > dependencies need it. In this case, USE flags only make this
> > auto-switching harder.
> 
> That is the other part of this idea, to make auto-switching harder,
> because right now portage likes to auto-switch even when it seems like
> it shouldn't.

This is a bug in portage and should be fixed there. As I said, working
it around will only fix it for one package, and it will happen again
and again, possibly in cases harder to pinpoint.

-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: PGP signature

Reply via email to