Gentoo Archives: gentoo-project

From: Michael Palimaka <kensington@g.o>
To: gentoo-project@l.g.o
Subject: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12
Date: Fri, 01 Aug 2014 19:41:16
Message-Id: lrgqfv$3u3$1@ger.gmane.org
In Reply to: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 by "Michał Górny"
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.

Replies