-----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. I personally don't use sets so i've no idea if the exact same thing could be accomplished in sets; for some reason i don't think so. > > 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. I figure this idea would also help with Ciaran's wishlist item of ||() deps becoming more strictly-controlled and readily deterministic. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPWgi8ACgkQ2ugaI38ACPBfoQD/bZmCxCdLM9EyeJRrst5QmD9X NS2Y0HCNhRnCfAuplUYA/2UHibYB6YHdKOi40RkWOUA0KMTRSwXYPR6dYsmByiQL =njwB -----END PGP SIGNATURE-----
