Re: Transition rebuilds done before the new version was available
On 26/07/2020 16:54, Samuel Thibault wrote:
> Hello,
>
> Emilio Pozuelo Monfort, le dim. 26 juil. 2020 13:02:58 +0200, a ecrit:
>> On 26/07/2020 09:52, Mattias Ellert wrote:
>>> Why are the transition binnmus not scheduled with an dep-wait on the
>>> new soname?
>>
>> From my experience, that causes more harm than good.
>
> Oh? I guess that really depends on the state of a given port? I guess
> you mean that some ports prefer to possibly stay with older versions of
> libraries when they are getting issues with newer versions, or such kind
> of "we can't actually move so fast yet" issues?
No, it's more about that if the newer library is not available (due to FTBFS or
bd-uninst for example) and we schedule binNMUs for rdeps with dep-wait, those
will get blocked too. If the initial library takes a long time to get fixed,
then those rdeps will also be blocked to build for other transitions, or if they
receive new uploads, which may cause further bd-uninst issues.
> For hurd-i386, I'd really rather see the dep-wait added, to avoid having
> to re-do the binnmu work of the transitions.
For these small transitions I just schedule one run covering all architectures.
What I generally try to do is to wait for the slower architectures to build the
library so that the binNMUs are useful, something that I forgot to do for the
case at hand.
For larger transitions (say perl) I take proper care of port architectures
(scheduling binNMUs later if necessary), but that's too much work for the
smaller ones.
The solution to all this is to have better tooling, until then this is best
effort for port architectures.
Cheers,
Emilio
Reply to: