Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12

[Michał Górny]

Dnia 2014-08-01, o godz. 00:40:18
Michael Palimaka <kensington@g.o> 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