[postgis-devel] liblwgeom symbols exported by postgis module

Paragon Corporation lr at pcorp.us
Thu Oct 1 10:03:55 PDT 2015


> Now back to Regina's problem:
> if we have a generic SONAME, the Debian policy would make it possible, on
a security update, to have a PostGIS-2.2.0 end up using a liblwgeom-2.2.1.
This is because the package containing the postgresql module might depend on
"liblwgeom2 (>= 2.2.0)", > thus accepting for liblwgeom to be in-place
upgraded from 2.2.0 to 2.2.1.

> According to Debian policy this is good, because it (for example) fixes a
crash in an existing installation. But according to Regina this is bad
because then you can't easily tell which version of PostGIS is a debian user
running, and that's because SELECT
> postgis_full_version() reports the same output for both users using
> PostGIS-2.2.0/liblwgeom-2.2.0 and users using
PostGIS-2.2.0/liblwgeom-2.2.1.

> Is this the problem, Regina ?

> --strk; 
Yes and no.  I'm more concerned about PostGIS 2.1.9 using PostGIS 2.2.0,
which could happen on windows if they have the same liblwgeom name and I
build dynamically.


Bas,
If I understand you would this not be  possible on Debian. - I was unclear
if 2.1.9 would be considered < 2.2.0

This is more of a concern because 2.1.9 might have security updates or bug
fixes that 2.2.0 does not and so we'd have users complaining about things we
already fixed thinking they are running something newer than they are.


I'd feel more comfortable if our postgis_full_version() listed the version
of liblwgeom just in case such a thing were to happen where they become
disconnected.
Unlike the case with SpatiaLite where liblwgeom is just another convenient
library like GEOS etc, liblwgeom largely defines PostGIS so why do I want to
split my heart apart.


Now as far as windows is concerned I suspect it's much more common for
people to be running two versions of PostGIS on the same instance, just
because I make it much easier to do so and my clients want that for
regression testing.

Given most dependencies live in the PostgreSQL bin folder on windows, I
don't much care having liblwgeom detached from PostGIS because from the
server perspective, that's really the only thing that matters and I don't
want someone building an extension accidentally using my version of
liblwgeom.


Most other dependencies I do dynamically link such as the curl/ssl/libxml I
will be pushing with PostGIS 2.2 since if EDB updates the postgres with an
ssl  security fix, I do want users to be able to get that.  I don't even
bother distributing these along with PostGIS because I want users to use the
one that came with their PostgreSQL install, though I do pay careful
attention to building with the same or compatible versions as EDB ships.


Thanks,
Regina











More information about the postgis-devel mailing list