[postgis-devel] PSC Vote: Drop the minor in the postgis lib files

[Sebastiaan Couwenberg]

On 9/27/18 4:44 PM, Sandro Santilli wrote:
> On Thu, Sep 27, 2018 at 10:29:29AM -0400, Paul Ramsey wrote:
> 
>> Correct. We (our packagers) have some packaging issues that make it
>> hard for people to actually put that situation into action (I believe
>> on debian the issue is a collision in liblwgeom which doesn’t support
>> multiple installed versions at once, and on rhat just some poor choices
>> in terms of depends/supercedes declarations) but if you can in fact have
>> a target with the right versions in place things just Work.
> 
> I'd love to hear more about this from packagers.
> What prevents them to ship at the same time a combination
> of packages like what I see in the output of my command:
> 
> # apt-cache search postgis-2.4 | grep -v scripts
> postgresql-10-postgis-2.4 - Geographic objects support for PostgreSQL 10
> postgresql-9.3-postgis-2.4 - Geographic objects support for PostgreSQL 9.3
> postgresql-9.4-postgis-2.4 - Geographic objects support for PostgreSQL 9.4
> postgresql-9.5-postgis-2.4 - Geographic objects support for PostgreSQL 9.5
> postgresql-9.6-postgis-2.4 - Geographic objects support for PostgreSQL 9.6
> 
> NOTE: the above come from http://apt.postgresql.org

That is a 3rd party repository, not part of Debian. Debian has different
policies from the PGDG repo.

There is only a single PostgreSQL version in a Debian release, the
postgis package is built for that version, no others.

When users upgrade from, for example, jessie to stretch, they need to
upgrade their database cluser from postgresql-9.4 with
postgresql-9.4-postgis-2.1 (which provides postgis-2.1.so) to
postgresql-9.6 with postgresql-9.6-postgis-2.3 (which provides
postgis-2.3.so).

pg_upgrade fails because the new cluster does not have postgis-2.1. And
users are forced to recreate their database from scatch if they don't
want to use the symlink hacks which require modifying paths managed by
the packaging system. Those symlinks will not be remove with their next
distribution upgrade because they are not part of a package that is
being removed leaving cruft on the users filesystem they have to
manually cleanup.

Regarding the PGDG repo, one the reasons the PGDG repo exist is to
provide users with packages for older (still supported) postgresql
releases so they are not forced to upgrade their cluster when they do a
distribution upgrade, which may not very feasible for very large databases.

Kind Regards,

Bas