1 |
On 06/07/2016 04:59 PM, Michał Górny wrote: |
2 |
>> |
3 |
>> I'll believe this when I see it =P |
4 |
> |
5 |
> You won't because the Gentoo way is to create a shitload of hacks |
6 |
> instead of fixing the root issue. |
7 |
> |
8 |
|
9 |
I'm not arguing for anything here, I'm just toying around with an idea |
10 |
for fun. What we want is a way to declare USE flag constraints within an |
11 |
ebuild that, |
12 |
|
13 |
1) Runs quickly |
14 |
2) Prevents a package from being installed with conflicting flags |
15 |
3) Preferably has a simple grammar and doesn't require bash |
16 |
4) Outputs a sensible message to the user upon conflict |
17 |
|
18 |
The error message is the one clear point that pkg_pretend holds over |
19 |
REQUIRED_USE. If we can make portage do something sensible when it hits |
20 |
a REQUIRED_USE conflict, that would be ideal. But aren't (2) and (4) the |
21 |
most important points? |
22 |
|
23 |
|
24 |
>> |
25 |
>> So 7 minutes for an understandable English description of the error and |
26 |
>> how to fix it, versus 5 minutes for line noise? There's a great story in |
27 |
>> The Psychology of Computer Programming that ends like this: |
28 |
> |
29 |
> Not 5 minutes. Depending on the context, Portage can complain about |
30 |
> REQUIRED_USE in a few seconds because it has no further point |
31 |
> in evaluating the depgraph. |
32 |
> |
33 |
|
34 |
It doesn't do this, does it? I think it waits until the end. It *could* |
35 |
run pkg_pretend earlier, too, but it doesn't. |
36 |
|
37 |
|
38 |
> |
39 |
>>> 3. REQUIRED_USE can take USE dependencies into account. pkg_pretend() |
40 |
>>> can't. |
41 |
>> |
42 |
>> What do you mean here? |
43 |
> |
44 |
> I mean that if A depends on B[gtk2], and you have ^^ ( gtk2 gtk3 ), |
45 |
> Portage will clearly know gtk2 is the only solution. Your pkg_pretend() |
46 |
> will tell user to enable gtk3, then Portage will hit unsolvable deps. |
47 |
> Congratulations, your helpful output just resulted in even worse |
48 |
> output! |
49 |
> |
50 |
|
51 |
gtk2 is not the only solution: I could set B[gtk2] and A[gtk3] in |
52 |
package.use. (If gtk2 *were* the only solution, then why would you have |
53 |
the REQUIRED_USE in the first place? Just pass --with-gtk2.) |
54 |
|
55 |
In practice, I would set A[gtk3] in package.use, and then try to emerge |
56 |
it again. Portage would tell me that I needed to set B[gtk2] first, and |
57 |
I would do that and start over. |
58 |
|
59 |
|
60 |
>> See #2, but "each package" is an overestimate. Only the ones with a |
61 |
>> non-trivial pkg_pretend() phase would take any time. |
62 |
> |
63 |
> Have you tried it, or is it wild guess? What I'm saying is that |
64 |
> *pkg_pretend implementation in Portage is TERRIBLY SLOW*. Even |
65 |
> a complete no-op takes a lot of time because Portage needs to do a lot |
66 |
> of setup to run it, and can't do multiple packages in parallel. |
67 |
> |
68 |
|
69 |
Of course I haven't tried it =) |
70 |
|
71 |
One of two scenarios holds, though: |
72 |
|
73 |
* if a trivial pkg_pretend() is slow, then one that checks for USE |
74 |
flag conflicts isn't actually that much slower. |
75 |
|
76 |
* if a trivial pkg_pretend() is fast, then only those packages that |
77 |
have a non-trivial pkg_pretend() make it slower. |
78 |
|
79 |
REQUIRED_USE should be faster either way, but that's currently at the |
80 |
expense of the error messages and I'm not sure those *can* be fixed. |