Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg <myon@debian.org>]

Re: Sebastiaan Couwenberg
> Since the upgrade procedure documented in the release notes includes
> purging removed and obsolete packages, users are not expected to keep
> libgda20 around after the distribution upgrade.

To avoid exactly this problem, postgresql-common is maintaining a list
of PG versions that have clusters on the system:

/etc/apt/apt.conf.d/01autoremove-postgresql

APT
{
  NeverAutoRemove
  {
    "^postgresql.*-11";
    "^postgresql.*-13";
  };
};

... so libgdal20 will not be autoremoved because
postgresql-11-postgis-2.5 is not autoremoved. The list is updated once
you `pg_dropcluster 11 main`.

> There is much less need for gdal-data breaking libgdal20 for us than
> there is in the UbuntuGIS PPA use case. I'm not aware of any packages
> that use gdal in the maintainer scripts that would be using the old gdal
> on their removal. So there shouldn't be any actual expected breakage.

I don't know the GIS world enough to be able to say what the data
files in gdal-data are good for, but my guess would be that for the
"read geometry data from an old postgresql-11 cluster", which is what
we need for pg_upgradecluster, they aren't relevant, and just making
libgdal20 co-installable is enough.

People shouldn't be expecting to be able to use the old postgis to do
complex data type (gdal?) or coordinate system (proj?) transformations
on a system that has already been upgraded to the new library versions
anyway.

> This change is minimal, doesn't require NEW packages, nor introduces
> divergence from upstream (as when the files would be moved to
> u/s/gdal/<X.Y> in libgdal28), hence it's my preferred solution.
> 
> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
> changes from the debdiff to unstable.

Sounds good to me, thanks!

Christoph