1 |
Dnia 2014-07-25, o godz. 14:49:44 |
2 |
Ian Stakenvicius <axs@g.o> napisał(a): |
3 |
|
4 |
> Hey all.. So, putting aside for now how much of a mess this would be |
5 |
> to implement in the virtuals' ebuilds themselves, what do people think |
6 |
> of changing the virtuals so that they contain an entry in IUSE for |
7 |
> each provider that can satisfy it? |
8 |
> |
9 |
> The idea here is that the package satisfying a virtual could be |
10 |
> optionally explicitly-chosen through package.use (or USE= in |
11 |
> make.conf, perhaps) instead of having an entry in @world, that way if |
12 |
> nothing depends on the virtual then it and the provider can be |
13 |
> - --depclean'ed from the system. The idea is specifically NOT to have |
14 |
> rdeps depend on these flags, that would undermine the whole purpose of |
15 |
> the virtual; it would just be for end-users to set if they so chose. |
16 |
|
17 |
I think I don't get this argument. |
18 |
|
19 |
If you really want to have a particular provider for the virtual for |
20 |
external purposes, it's fully purposeful to put it in @world or |
21 |
otherwise in a custom set. In this case, USE flags aren't helpful. |
22 |
|
23 |
If you only prefer a particular provider, you can tip portage easily to |
24 |
use it without resorting to USE flags. This also allows portage to |
25 |
semi-transparently switch to other provider if dependencies need it. |
26 |
In this case, USE flags only make this auto-switching harder. |
27 |
|
28 |
> This may also help with getting portage to peg a virtual's provider to |
29 |
> a specific package instead of constantly trying to switch from one to |
30 |
> another, ie, how systemd kept getting pulled in, in relation to the |
31 |
> upower virtual. Note - I haven't done any tests to determine if this |
32 |
> actually helps with such issues tho (or even attempted to reproduce |
33 |
> them, as i was apparently one of the lucky ones that it didn't happen to). |
34 |
|
35 |
While I agree that finding some solution is a good step forward, I'm |
36 |
afraid this doesn't really lead us anywhere. Even if it allows to |
37 |
workaround the actual portage issue, I'm afraid we will hit it again |
38 |
somewhere else. Shortly, Gentoo would be full of workarounds... oh |
39 |
wait, it already is. |
40 |
|
41 |
By the way, proper virtuals for krb5 would involve much more crazy |
42 |
stuff to get slot operator right. And then Ciaran would yell at us for |
43 |
abusing slots. |
44 |
|
45 |
-- |
46 |
Best regards, |
47 |
Michał Górny |