1 |
Thanks for taking the time to compose a reply that actually has some |
2 |
substance - you're the only person involved with Portage that has |
3 |
bothered so far. |
4 |
|
5 |
On 08/01/2014 05:12 AM, Micha³ Górny wrote: |
6 |
|
7 |
>> If we are to change our default dependency model, we need to do it |
8 |
>> properly - we need wider consensus, more open discussion of what's |
9 |
>> happening, and a proper plan of how to handle the pitfalls of the new |
10 |
>> model. Otherwise, we're just trading one set of problems for another. |
11 |
> |
12 |
> Yes, exactly. We need to get dynamic-deps right if they are ever |
13 |
> supposed to become the default. That's one of the reasons that we want |
14 |
> to revert the problematic changes and make Portage use the default |
15 |
> model once again. |
16 |
What do you mean? Dynamic dependencies are the current default by |
17 |
definition. |
18 |
|
19 |
>> Specifically, I request the Council block the removal of dynamic |
20 |
>> dependencies until the following issues are resolved: |
21 |
>> |
22 |
>> 1. Although there has been considerable discussion[2] regarding dynamic |
23 |
>> dependencies in general, there has been no specific discussion regarding |
24 |
>> their actual removal. |
25 |
> |
26 |
> The thread pretty quickly turned into a bikeshed about that, so I don't |
27 |
> understand what you're talking about. |
28 |
Perhaps I missed it due to the size of the thread, but the discussion |
29 |
appeared to be more abstract rather than concerning any definite change. |
30 |
I see relatively little comment from Portage team members in any case. |
31 |
|
32 |
>> 2. The Portage team had made no announcement of their decision, nor do |
33 |
>> they apparently intend to until 30 days prior to a new Portage release. |
34 |
>> This is not adequate time for such a substantial change. |
35 |
> |
36 |
> I don't know what you mean by 'they apparently intend' but that sounds |
37 |
> offensive. I'd really prefer if you sticked to the facts. |
38 |
How is that offensive? It is the apparent intention I've been able to |
39 |
discern from the limited information the Portage team is providing. |
40 |
|
41 |
> The Portage team is going to announce the decision when it's final |
42 |
> and the code necessary for non-painful migration is in place. |
43 |
> Otherwise, the announcement would only bring barren discussion that |
44 |
> couldn't be supported by facts or numbers. |
45 |
This is not acceptable for such a significant change. |
46 |
|
47 |
>> 3. Few of the Portage team members were present[3] for the meeting, and |
48 |
>> no vote was held to reach the decision. |
49 |
> |
50 |
> I don't understand how this is relevant. |
51 |
It's not acceptable for one or two people to make a decision that |
52 |
affects the entire distribution, let alone if they don't have the |
53 |
consensus of their own team. |
54 |
|
55 |
>> 4. While there is a good description of the theoretical issues affecting |
56 |
>> both dependency models[4], multiple requests for specific examples of |
57 |
>> in-tree breakage have been ignored. This makes it difficult to assess |
58 |
>> the actual breakage that removing dynamic dependencies is supposed to |
59 |
>> address. |
60 |
> |
61 |
> The listing of theoretical issues is wrong and doesn't correspond to |
62 |
> Portage code, and yes, that's my fault. However, it only proves that |
63 |
> nobody on the thread bothered to look at the relevant Portage code, |
64 |
> even the people who started providing patches... |
65 |
The burden of proof is on the person wanting to make the change, so it |
66 |
would be nice if the Portage team would provide better information. |
67 |
Despite repeated requests, we have little information to substantiate |
68 |
claims like "it's fundamentally broken" and "dynamic dependencies is a |
69 |
bug. We decided to fix this regression." |
70 |
|
71 |
>> 5. The removal plan doesn't consider the impact from increased number of |
72 |
>> rebuilds due to revbumps containing only dependency changes. Without |
73 |
>> replacement functionality, widespread virtual or slot changes can cause |
74 |
>> hundreds of packages to be rebuilt. |
75 |
> |
76 |
> Please support this claim with specific examples or numbers. Otherwise, |
77 |
> it's just a 'theoretical issue' that you can't support. |
78 |
I'm happy to provide more examples beyond the 77 |
79 |
useless-but-apparently-acceptable rebuilds you mentioned below if |
80 |
necessary. It's not hard to check yourself, though. Almost 9000 ebuilds |
81 |
depend on virtual/pkgconfig. Even if we assume that any future virtual |
82 |
introduction will only affect an absolute maximum of 10% of that number |
83 |
of packages, that's still a ridiculous number of unnecessary rebuilds. |
84 |
|
85 |
> There is a lot of FUD about unnecessary rebuilds. Sadly, most people |
86 |
> seem to fight a holy war against them without realizing the real |
87 |
> impact. In fact, more unnecessary rebuilds are caused by unnecessary |
88 |
> USE flags than by dependency changes. |
89 |
Do you have some numbers to back up that statement? I can think of very |
90 |
few instances when I have had to rebuild against my will due to USE flag |
91 |
changes. |
92 |
|
93 |
> Yet the same people believe in |
94 |
> adding more flags to contain even more minor aspects of packages... |
95 |
Are you referring to flags for things like logrotate or systemd units? |
96 |
When they were around, I either had them enabled or I didn't - I was |
97 |
never forced to rebuild because of them. |