1 |
Dnia 2014-07-28, o godz. 13:02:39 |
2 |
Ian Stakenvicius <axs@g.o> napisał(a): |
3 |
|
4 |
> -----BEGIN PGP SIGNED MESSAGE----- |
5 |
> Hash: SHA256 |
6 |
> |
7 |
> On 28/07/14 07:21 AM, Michał Górny wrote: |
8 |
> > Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius <axs@g.o> |
9 |
> > napisał(a): |
10 |
> > |
11 |
> >> Hey all.. So, putting aside for now how much of a mess this |
12 |
> >> would be to implement in the virtuals' ebuilds themselves, what |
13 |
> >> do people think of changing the virtuals so that they contain an |
14 |
> >> entry in IUSE for each provider that can satisfy it? |
15 |
> >> |
16 |
> >> The idea here is that the package satisfying a virtual could be |
17 |
> >> optionally explicitly-chosen through package.use (or USE= in |
18 |
> >> make.conf, perhaps) instead of having an entry in @world, that |
19 |
> >> way if nothing depends on the virtual then it and the provider |
20 |
> >> can be - --depclean'ed from the system. The idea is specifically |
21 |
> >> NOT to have rdeps depend on these flags, that would undermine the |
22 |
> >> whole purpose of the virtual; it would just be for end-users to |
23 |
> >> set if they so chose. |
24 |
> > |
25 |
> > I think I don't get this argument. |
26 |
> > |
27 |
> > If you really want to have a particular provider for the virtual |
28 |
> > for external purposes, it's fully purposeful to put it in @world |
29 |
> > or otherwise in a custom set. In this case, USE flags aren't |
30 |
> > helpful. |
31 |
> |
32 |
> The argument I was trying to make is that USE flags would allow |
33 |
> end-users to accomplish the same thing, while not having an entry in |
34 |
> @world and therefore allowing the package to be --depclean'ed if the |
35 |
> virtual is --depcleaned. |
36 |
|
37 |
If you need it externally, you need it not depcleaned, obviously. So |
38 |
you have to have something in @world. If you need a specific |
39 |
implementation, it's more elegant to put that in @world rather than |
40 |
the virtual and playing with USE flags. |
41 |
|
42 |
> > If you only prefer a particular provider, you can tip portage |
43 |
> > easily to use it without resorting to USE flags. This also allows |
44 |
> > portage to semi-transparently switch to other provider if |
45 |
> > dependencies need it. In this case, USE flags only make this |
46 |
> > auto-switching harder. |
47 |
> |
48 |
> That is the other part of this idea, to make auto-switching harder, |
49 |
> because right now portage likes to auto-switch even when it seems like |
50 |
> it shouldn't. |
51 |
|
52 |
This is a bug in portage and should be fixed there. As I said, working |
53 |
it around will only fix it for one package, and it will happen again |
54 |
and again, possibly in cases harder to pinpoint. |
55 |
|
56 |
-- |
57 |
Best regards, |
58 |
Michał Górny |