1 |
On 06/07/2016 02:57 PM, Michał Górny wrote: |
2 |
> |
3 |
> The point is that: |
4 |
> |
5 |
> 1. REQUIRED_USE is semi-machine-understandable while pkg_pretend() is |
6 |
> some random function crap. |
7 |
|
8 |
Why do users care about that? Why do I even care about that? The whole |
9 |
ebuild is random function crap. The only benefit is consistent output, |
10 |
but it's consistently awful. |
11 |
|
12 |
|
13 |
> Portage can be improved to take some sensible action on it. |
14 |
|
15 |
I'll believe this when I see it =P |
16 |
|
17 |
|
18 |
> 2. REQUIRED_USE can be handled early during dependency resolution. |
19 |
> pkg_pretend() is like I want 5 minutes for Portage to calculate |
20 |
> the dependencies, then 2 minutes to run pkg_pretend()s, then it tells |
21 |
> me I am supposed to change one thing and start over. |
22 |
|
23 |
So 7 minutes for an understandable English description of the error and |
24 |
how to fix it, versus 5 minutes for line noise? There's a great story in |
25 |
The Psychology of Computer Programming that ends like this: |
26 |
|
27 |
"And how long does your program take?" he asked--emphasizing the |
28 |
possessive. |
29 |
|
30 |
"That varies with the input," was the reply, "but on average, about |
31 |
ten seconds per card." |
32 |
|
33 |
"Aha," was the triumphant reply. "But my program takes only one |
34 |
second per card." |
35 |
|
36 |
The members of the audience--who had, after all, all contributed to |
37 |
the one-second version--seemed relieved. But our hero, who was rather |
38 |
young and naive, was not put down by this remark. Instead, he calmly |
39 |
observed, "But your program doesn't work. If the program doesn't have |
40 |
to work, I can write one that takes one millisecond per card--and |
41 |
that's faster than our card reader." |
42 |
|
43 |
|
44 |
> |
45 |
> 3. REQUIRED_USE can take USE dependencies into account. pkg_pretend() |
46 |
> can't. |
47 |
|
48 |
What do you mean here? |
49 |
|
50 |
|
51 |
> 4. pkg_pretend() is slow, and should be used scarcely. Adding |
52 |
> an additional slow step for each package on the list, before starting to |
53 |
> build packages is not really helpful. |
54 |
> |
55 |
|
56 |
See #2, but "each package" is an overestimate. Only the ones with a |
57 |
non-trivial pkg_pretend() phase would take any time. |