[postgis-devel] liblwgeom symbols exported by postgis module
Sandro Santilli
strk at keybit.net
Thu Oct 1 01:22:00 PDT 2015
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.
> 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 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.
> 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 ?
That'd leave users with not knowing exactly what
version of PostGIS they are using, as "SELECT postgis_full_version()"
won't tell them about the version of liblwgeom, currently.
> 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.
Note that if a security fix is included in a new version of liblwgeom,
for sure that same security if is also included in a new version of
postgis, as they are always released togheter... until that changes.
> >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.
This should be common on upgrades.
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.net/services.html
More information about the postgis-devel
mailing list