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
