On Thu, Nov 13, 2025 at 10:24:05AM +0100, Paul Gevers wrote: >... > Can you please elaborate on what exactly you think britney should do. Until > now I haven't really been able to construct the right logic without dropping > the smooth transition concept. While not being perfect, smooth transitions > are an important tool for the release managers. I *think* (but I could be > wrong) that what you want is conflicting with that. (At least, without > having out-of-the-archive information about ongoing transitions). >...
The fundamental issue is that it is usually not safe to mix different soversions of a library in a binary. This is not a test-only issue. Users in testing might run into the same problem. It might also show up during upgrades from oldstable to stable. Or in backports. On Thu, Nov 13, 2025 at 12:31:31PM +0100, Paul Gevers wrote: >... > Not implying it's worth the effort (and maybe it would be dumb for other > reasons), but this Provides *could* encapsulate the SONAME of libgdal that > it got compiled against and then the libgdal-grass rebuild could lock into > that. >... That's extra work for the maintainer, and won't cover cases like users of backports unintentionally mixing different soversions through other libraries. The proper way to avoid all these issues would be Package: libgdal38 Breaks: libgdal37 I think proper Breaks would not result in transitions becoming completely non-smooth, since different packages in level 2 (with disjoint sets of rdeps in higher levels of the transition) should still be able to transition independently when the package that started the transition does not have strict dependencies with binary-all. So instead of trying to avoid the tip of breakage that shows up in autopkgtests, I wonder if I miss any reason why the proper fix of Breaks: libgdal37 wouldn't keep the transition smooth except that the package dependencies would ensure that libgdal-grass has to both migrate and be tested together with the rebuilt grass. > Paul cu Adrian BTW: The octomap transition is currently blocked for the same reason.
