[postgis-devel] liblwgeom symbols exported by postgis module

[Sandro Santilli]

On Thu, Oct 01, 2015 at 09:05:28AM +0200, Sandro Santilli wrote:
> On Thu, Oct 01, 2015 at 08:46:46AM +0200, Sebastiaan Couwenberg wrote:
> > 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.
> 
> Just to get this straight, are the current packages for PostGIS
> requiring a specific full-version of liblwgeom ? I read (for postgis):
> 
>  Depends: ...  liblwgeom-2.1.2 (>= 2.0.0) ...
> 
> What's the ">= 2.0.0" string about ?
> Would any existing differently named package satisfy such dependency ?
> Would changing the soname make that dependency somewhat looser ?

Sorry, I was looking at the wrong package. The "postgis" one evidently
is for the executables (shp2pgsql/pgsql2shp). The one containing the
PostgreSQL module is named something like "postgresql-9.3-postgis-2.1"
and the liblwgeom dependency line is:

 liblwgeom-2.1.2 (>= 2.1.2)

Same question applies: what does that version match, when the package
name is really different ? I guess it's just a useless match.

I also now realize that package names are ortogonal to the SONAME
discussion, aren't them ? So you could still name your packages
"libwgeom-2.2.0" if you wanted to allow for keeping multiple
patch-level versions of the library installed at the same time.

But of course the SONAME is what gets referenced within the client
code, that is the binaries and (for Debian) the PostgreSQL module,
so even if you name your packages differently, having the same SONAME
means getting the client code automatically use whatever the operating
system considers to be the latest version of that SONAME.

This means that so far, SONAME containing the _full_version_ it should
have not be different from static linking (except for behavior in case
of loading multiple liblwgeom clients in the same PostgreSQL backend
process).

Did the "multiple liblwgeom clients (aka multiple postgis modules) in
the same PostgreSQL backend process" hit users on upgrade ? Is this
the problem with Debian packages ?

I suggest we first try to address any existing issue, and then see
if/how moving to a different SONAME changes those issues.

--strk; 

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