Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
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.
> 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
Reply to: