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. 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. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
