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
