[postgis-devel] liblwgeom symbols exported by postgis module

[Sebastiaan Couwenberg]

On 01-10-15 06:13, Paragon Corporation wrote:
> I think Debian folks are most affected by this since they change our code to
> dynamically link.  So I'm most concerned what they think

liblwgeom-2.2.so.2 is not much of a benefit over the old liblwgeom-2.1.8
naming, although it won't break the SONAME at every patch release any more.

> Now there is one question I have for Sebastian and rest of Debian crew about
> how they manage PostGIS distributions.  You say you only distribute one
> version of PostGIS per PostgreSQL release.
> 
> Does this mean:
> 
> a) Since you shipped PostgreSQL 9.4 with PostGIS 2.1, you will never be
> shipping PostGIS 2.2 for PostgreSQL 9.4?  
> That would really suck since there would be no easy path to upgrade for
> users.

In the distribution itself we'll have a single postgis version, not
having an easy upgrade path is a known issue with postgis. A big
disappointment when I first started using it, being used to just upgrade
my cluster, but having the reimport my spatial databases which is much
more time consuming. Having postgis support in pg_upgradecluster would
be my preferred solution to not require users to recreate their postgis
databases.

Because I won't backport GEOS 3.5.0 for jessie, I'm in doubt if it's
worthwhile to update the postgis backport from 2.1.8 to 2.2.0 when it
migrates to testing.

If I do decide to backport 2.2 Debian stable users will have 2.1.4 and
2.2.0 available with postgres 9.4.

> or
> b) Since you consider it a standard upgrade when PostGIS 2.2 comes out your
> PostgreSQL 9.4 offering will then switch to PostGIS 2.2 and you'll uninstall
> PostGIS 2.1?
> This option would have me a bit concerned as it would mean peoples PostGIS
> databases would be broken until they rush to do a 
> 
> ALTER EXTENSION postgis UPDATE;
> 
> On all of them -- so that would be a disclaimer we would need to flag.
> The uninitiated user would be panick stricken - and worst yet if they had
> just some sys admin with no PostgreSQL/PostGIS experience doing the standard
> system upgrade all packages they could be down for hours.

This should not be a surprise. This is the status quo for postgis on
Debian. Uninitiated users are fucked anyway as they are not able to
solve their issues by definition, that's why competent IT staff is
valuable, they are at least able to read the documentation and use a
search engine to find a solution.

> or
> 
> c) Since you consider it a standard upgrade when PostGIS 2.2 comes out your
> PostgreSQL 9.4 offering will then switch to PostGIS 2.2, but you'll keep
> PostGIS 2.1 if installed?
> - for selfish reasons I would prefer this (since it means we have more users
> being able to use 2.2 (and can focus more attention on our newer offering)
> though not necessarily the best solution for everyone
> Since they could be running with an outdated 2.1 unless they are experienced
> users.

Your version specific thinking is wrong for Debian. We have a single
postgresql version in a Debian stable release, and likewise have a
single postgis version in a Debian stable release (there is
apt.postgresql.org if you need other versions).

We'll move postgis 2.2 to unstable when the final release is out and the
previous rc1 uploads have passed the NEW queue after FTP master review
(thanks to the separate package required for postgis-java among others).
Our decision to upgrade the postgis package from 2.1.8 to 2.2.0 is
independent of the decisions the postgres maintainers make about their
upgrade from 9.4 to 9.5.

Because postgis packages are partially co-installable upgrading to 2.2
doesn't imply the removal of the 2.1 packages, some of them will be left
installed but in a not guaranteed to work state.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1