Re: Transition rebuilds done before the new version was available
Emilio Pozuelo Monfort, le lun. 27 juil. 2020 10:04:39 +0200, a ecrit:
> On 26/07/2020 16:54, Samuel Thibault wrote:
> > 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.
I guess you are here talking about the same of ports with
smooth-upgrade, which allow such transition decoupling?
In debian-ports with mini-dak we won't have both libraries available,
only the latest, and thus a binary package still depending on the old
library will not be installable anyway, so having it in dep-wait state
is really just the same.
> The solution to all this is to have better tooling,
> until then this is best effort for port architectures.
Yes, sure, but I mean it seems to me that precisely for debian-ports
with mini-dak, it seemed to me that dep-wait is actually no different
than installed-but-needs-an-nmu.
Samuel
Reply to: