Bug#1120361: transition: gdal
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.
Reply to: