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
