[postgis-devel] liblwgeom symbols exported by postgis module

[Bas Couwenberg]

On 2015-10-01 09:27, Sandro Santilli wrote:
> 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.

In the above example the package is named liblwgeom-2.1.2 to match the 
library SONAME (liblwgeom-2.1.2.so).

For 2.2 we have liblwgeom2 to match the SONAME liblwgeom.so.2.

The version (>= 2.1.2) is determined based on the symbols used by the 
dependent package, it uses at least one symbol introduced in PostGIS 
2.1.2 so at least this version is required.

For 2.2.0rc1 the following dependencies are used:

  postgis                    depends on liblwgeom2 (>= 2.0.0)
  postgresql-9.4-postgis-2.2 depends on liblwgeom2 (>= 2.2.0~rc1)

So the binaries included in the postgis package don't use any liblwgeom 
symbols introduced after 2.0.0, only the postgis module requires newer 
liblwgeom symbols.

> 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.

The Debian Policy requires that the library package name matches the 
SONAME, diverging from this should only be done for very good reasons:

"
The run-time shared library must be placed in a package whose name 
changes whenever the SONAME of the shared library changes. This allows 
several versions of the shared library to be installed at the same time, 
allowing installation of the new version of the shared library without 
immediately breaking binaries that depend on the old version. Normally, 
the run-time shared library and its SONAME symlink should be placed in a 
package named librarynamesoversion, where soversion is the version 
number in the SONAME of the shared library. Alternatively, if it would 
be confusing to directly append soversion to libraryname (if, for 
example, libraryname itself ends in a number), you should use 
libraryname-soversion instead.
"

http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime

> 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).

The difference with static linking is copying the code, and hence 
multiple places where bugs needs to be fixed instead of only the single 
dynamically linked shared library.

Security updates in the stable distribution are only applied to the 
shared library in question, any packages statically linking it won't be 
rebuilt to include the bug fix.

So no matter what SONAME postgis uses, Debian will continue to 
dynamically link liblwgeom to not punish the Security Team for 
deficiencies in upstream development.

> 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 don't know, may be Markus has experience with this use case.

Kind Regards,

Bas