[postgis-devel] liblwgeom symbols exported by postgis module

[Sandro Santilli]

On Thu, Oct 01, 2015 at 11:17:55AM +0200, Bas Couwenberg wrote:

> The only way your theoretical case makes sense is for the newer
> version. Debian won't rebuild the postgis 2.1.6 package when 2.1.8
> is uploaded to the archive. The strict dependencies on the exact
> binary version make sure that the liblwgeom-dev package pulls in the
> the same liblwgeom version, liblwgeom-dev (2.1.8+dfsg-4) Depends:
> liblwgeom-2.1.8 (= 2.1.8+dfsg-4), and liblwgeom-dev
> (2.2.0~rc1+dfsg-1~exp1) Depends: liblwgeom2 (=
> 2.2.0~rc1+dfsg-1~exp1).

Alright, so what would happen right now on a security fix (say in
postgis 2.1.3) is that a _new_ package "liblwgeom-2.1.3" will be installed
in parallel to the existing "liblwgeom-2.1.2" so that both the PostgreSQL
module in package "postgresql-9.3-postgis-2.1" - dep. on liblwgeom-2.1.2
(>= 2.1.2) - and the binaries in package "postgis" - dep. on
liblwgeom-2.1.2 (>= 2.0.0) - will still link against liblwgeom-2.1.2.so ?

That basically mean only new builds on the machine would benefit from
the security fix, right ?

My theoretical case was about old PostGIS using new liblwgeom.
This is currently (with ever-changing SONAME) not possible
(other than as an unwanted side-effect of loading both old and new
liblwgeom libraries in the same executable via dlopen).

Now for the unwanted side-effect:
imagine a developer makes a new PostgreSQL module, meant to work
with PostGIS. Security update got liblwgeom-2.1.3 installed, so that's
what the new PostgreSQL module is going to link to.

On testing the new module, the same PostgreSQL backend ends up loading
both liblwgeom-2.1.2.so (NEEDED by the PostGIS module) and liblwgeom-2.1.3.so
(NEEDED by the custom module). At this point it is impossible to know
which version of each library function will be invoked, and (I found
out) it is even possible for a function in liblwgeom-2.1.2.so to be
calling another one coming from liblwgeom-2.1.3.so.

I understand there are two possible fixes for the case above:

 1) Have both modules list the same liblwgeom version in their
    NEEDED section

 2) Have both modules statically link liblwgeom

For sure solution (1) is more easily handled with a more general SONAME,
while solution (2) doesn't care at all about SONAME. So this case calls
for properly setting SONAME to match actual binary compatibility.

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; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html