Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-15 06:05:28, Sebastiaan Couwenberg wrote:
> On 6/14/21 9:55 PM, Sebastian Ramacher wrote:
> > On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
> >>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
> >>>> What actual problems do are solved by making them co-installable?
> >>>>
> >>>> So far the only actualy problem that has been identified is the need for
> >>>> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
> >>>> present.
> >>>
> >>> apt currently fails to find an upgrade path for libmrpt-dev (logfile
> >>> attached, no bug filed, yet). The only solution I could find so far was
> >>> the big hammer: adding a Breaks against libopencv-core3.2 (or similar)
> >>> to gcc-10-base.
> >>> With a co-installable libgdal20/libgdal28 this is gone because the huge
> >>> dependency trees no longer conflict with each other.
> >>>
> >>> Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade
> >>> issues. So I can concentrate on fixing the remaining incomplete
> >>> (unversioned) python (2) removal bits. ;-)
> >>
> >> If co-installable libgdal is a must, then I'd rather drop gdal-data and
> >> move its content back to libgdal28 with an override for the
> >> big-usr-share lintian issue. That's how it was a long time ago:
> >>
> >> https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a
> >>
> >> I'm not in favor of either option, though.
> >
> > Not having libgdal20 and libgdal28 co-installable makes it unneccessarly
> > hard to upgrade all of libgdal's reverse dependencies that also bumped
> > SONAMEs. That set of packages includes at least opencv, pdal, qgis,
> > vtk7, otb, mapnik, openscenegraph and gazebo. And then there are
> > probably even more that are reverse dependencies of those packages which
> > bumped SONAME. So this issues affects many many packages and is not
> > only related to postgis.
>
> Again, postgis database upgrades have never been supported. You're
> wasting your time on that.
>
> >From the many other packages I haven't seen other issues other than the
> partial upgrade with monteverdi which is fixed with Breaks/Replaces.
>
> I really need more concrete cases to justify changes to gdal that I
> don't like but will have to maintain.
If neither you as maintainer nor upstream care about upgrade without
data loss, I don't think postgis is suitable to be included in a stable
release. Best option moving forward is to get postgis and its reverse
dependencies removed from bullseye.
Cheers
>
> > In any case, all these options seem rather unsatisfying and fragile.
> > Manually building specific postgis versions against specific postgresql
> > versions seems like a recipe for desaster. If one screws up any of the
> > steps, one can only hope for a backup and needs to start over. libgdal's
> > co-installablity issue makes that even more brittle then necessary if
> > not impossible.
>
> As said before, upgrade support of postgis is shit. Upstream does not
> take that use case very seriously, although some of the postgis
> developers are as unhappy with that as we are.
>
> I don't have the time, energy, nor knowledge required to fix this
> upstream. So I've just been recreating my postgis databases in the new
> cluster after every distribution upgrade.
>
> > To be honest, from a package in Debian I would expect more. This is a
> > frustrating upgrade experience. And even if we cannot fix postgis
> > upgrades in time, having libgdal20 and libgdal28 not co-installable,
> > makes it only more painful for our users. So I'd say, yes, libgdal20 and
> > libgdal28 co-installablity is a must.
> >
> >> We can also drop the Breaks from gdal-data, and have libgdal20 be broken
> >> for the bits that use it. It will help with the dependency resolution.
> >
> > If a non-function libgdal20 would mean that even if if installed, it's
> > completely useless for the cases above, then no, that's not an option.
>
> The scope of how broken libgdal20 is without all of the data files it
> expects is difficult to determine. The data files are considered a hard
> dependency, hence the Breaks on libgdal20 due to the changes for PROJ 6.
>
> Kind Regards,
>
> Bas
>
> --
> GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
>
--
Sebastian Ramacher
Reply to: