[postgis-devel] liblwgeom symbols exported by postgis module

[Bas Couwenberg]

On 2015-10-01 10:22, Sandro Santilli wrote:
> On Thu, Oct 01, 2015 at 10:04:03AM +0200, Bas Couwenberg wrote:
>> On 2015-10-01 09:27, Sandro Santilli wrote:
> 
>> 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.
> 
> Makes sense. Does that mean you have your own way to know which
> symbols of a library is used by a binary ? I guess that cannot help
> in case the symbol exists but behaves differently.

Yes, we manage symbols files in the Debian package that define the 
version in which symbols are introduced:

http://anonscm.debian.org/cgit/pkg-grass/postgis.git/tree/debian/liblwgeom-2.1.8.symbols

This is documented in the Debian Policy:

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

Making incompatible changes and not bumping the SONAME is a sign of 
incompetent library management, that should be fixed by educating the 
developers.

>> The Debian Policy requires that the library package name matches the
>> SONAME, diverging from this should only be done for very good
>> reasons:
> 
> Makes sense.
> Assumes (as expected by SONAME) that upgrades of libraries with same
> SONAME are always backward compatible.

The point of a SONAME is to indicate binary compatibility, when the 
compatibility breaks the SONAME must change.

>> 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.
> 
> Well, bugs are still fixed in the same place, the difference is just
> in needing or not a _rebuild_ of the multiple packages statically
> linking the fixed library.

The hard part is determining which of the 20.000+ packages need a 
rebuild because they statically link the library, the dependencies don't 
express this relationship.

>> 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.
> 
> Alright, so it may theoretically happen, in a Debian system,
> that you end up with a PostGIS module version 2.1.6 using a liblwgeom
> version 2.1.8 ?

No, because the postgis module has liblwgeom-2.1.8.so in its NEEDED 
section.

Kind Regards,

Bas