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. But let's come back to postgis. I tried to look into upgrades and what users are expected to do here. Upstream's documentation on this topic can be found at https://postgis.net/workshops/postgis-intro/upgrades.html. So, what I gather from that is that one possible way to upgrade is: * Mark postgresql-11-postgis-2.5 as hold to ensure it's not removed. * Upgrade enough packages so that one gets the postgresql 13 development packages and postgresql-13 installed. * Manually build postgis 2.5.x against postgresql 13 and install it. * pg_upgradecluster * Finish the buster -> bullseye upgrade * Once postgresql-13-postgis-3 is installed, upgrade the postgis extension. I tried that starting from a minimal chroot only having postgis and postgresql installed, but was unable to end up with a set of packages which allows me to build postgis 2.5 against postgresql 13 without getting postgresql-11-postgis-2.5 removed first. And even if it worked, one would have to rebuild postgis 2.5.x at some point against libgdal28 to finish the upgrade. Next option: * pg_dumpall * Upgrade to bullseye * Build postgis 2.5.x against postgresql 13 and install the extensions. * pg_restore * Upgrade the postgis extension. This could work, I guess. But I didn't try it. Or, alternatively, first manually build postgis 3.1.x in buster: * Build postgis 3.1.x against postgresql 11 and install the extension * Upgrade the postgis extension. * Upgrade buster to bullseye * pg_upgradecluster Before running pg_upgradecluster one would probably need to rebuild postgis 3.1.x against postgresql 11 again because of libgdal28. Are there any other options? 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. 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. Cheers -- Sebastian Ramacher
signature.asc
Description: PGP signature
