Dnia 2014-08-01, o godz. 00:40:18 Michael Palimaka napisał(a): > I am disappointed that the Portage team declined to bring the issue of > disabling dynamic dependencies to the Council's attention themselves. I don't understand your disappointment. If you disagree with portage team decision, it is your duty to bring it to the Council. > If we are to change our default dependency model, we need to do it > properly - we need wider consensus, more open discussion of what's > happening, and a proper plan of how to handle the pitfalls of the new > model. Otherwise, we're just trading one set of problems for another. Yes, exactly. We need to get dynamic-deps right if they are ever supposed to become the default. That's one of the reasons that we want to revert the problematic changes and make Portage use the default model once again. > Specifically, I request the Council block the removal of dynamic > dependencies until the following issues are resolved: > > 1. Although there has been considerable discussion[2] regarding dynamic > dependencies in general, there has been no specific discussion regarding > their actual removal. The thread pretty quickly turned into a bikeshed about that, so I don't understand what you're talking about. > 2. The Portage team had made no announcement of their decision, nor do > they apparently intend to until 30 days prior to a new Portage release. > This is not adequate time for such a substantial change. I don't know what you mean by 'they apparently intend' but that sounds offensive. I'd really prefer if you sticked to the facts. The Portage team is going to announce the decision when it's final and the code necessary for non-painful migration is in place. Otherwise, the announcement would only bring barren discussion that couldn't be supported by facts or numbers. > 3. Few of the Portage team members were present[3] for the meeting, and > no vote was held to reach the decision. I don't understand how this is relevant. > 4. While there is a good description of the theoretical issues affecting > both dependency models[4], multiple requests for specific examples of > in-tree breakage have been ignored. This makes it difficult to assess > the actual breakage that removing dynamic dependencies is supposed to > address. The listing of theoretical issues is wrong and doesn't correspond to Portage code, and yes, that's my fault. However, it only proves that nobody on the thread bothered to look at the relevant Portage code, even the people who started providing patches... > 5. The removal plan doesn't consider the impact from increased number of > rebuilds due to revbumps containing only dependency changes. Without > replacement functionality, widespread virtual or slot changes can cause > hundreds of packages to be rebuilt. Please support this claim with specific examples or numbers. Otherwise, it's just a 'theoretical issue' that you can't support. If you are really curious, I am working hard on providing tools to fix the vdb inconsistencies caused by dynamic-deps. There were no specific data because it wasn't available until today. My regularly updated desktop system (2-3 days between @world updates) after disabling dynamic-deps has 77 packages needing rebuild. That number includes a few virtuals, Perl packages and other low-effort cases. And this is after the big, scary virtual/*udev changes. Over the next days I will obviously have more numbers. More specifically, the number of packages needing rebuild after dependency changes made by developers. It should be noted that the above number includes one-time rebuild of packages that are simply ancient. There is a lot of FUD about unnecessary rebuilds. Sadly, most people seem to fight a holy war against them without realizing the real impact. In fact, more unnecessary rebuilds are caused by unnecessary USE flags than by dependency changes. Yet the same people believe in adding more flags to contain even more minor aspects of packages... -- Best regards, Michał Górny