[postgis-devel] Why do we still install liblwgeom includes

[Greg Troxel]

"Regina Obe" <lr at pcorp.us> writes:

>> Our current build setup statically links liblwgeom into postgis-*.so,
> rtpostgis-
>> *.so But some packages -- pointing my finger strongly at Debian folks,
> don't
>> like this and hack their configure scripts to prevent this.
>> 
>> https://sources.debian.org/patches/postgis/2.5.1+dfsg-1/link-liblwgeom/
>> https://trac.osgeo.org/postgis/ticket/3290
>> 
> [Regina Obe] 
> Two more reasons to prefer static linking for postgis extension libs and I
> would say for the commandline tools as well.
> As Darafei pointed out, if you compile postgis with SFCGAL support, your
> liblwgeom depends on SFCGAL which means EVERYTHING depends on SFCGAL.

That is a feature, not a bug.  Hiding dependencies does not make them go
away.

> However we observed that with postgis/rtpostgis statically linked to
> liblwgeom, the SFCGAL dependency in the .so is void of SFCGAL dependency.
> In fact rtpostgis has no dependency on GEOS if statically linked which is in
> the liblwgeom.so though GEOS is a dependency on the liblwgeom.so
>
> I think that was the original reason I statically linked my
> raster2pgsql/shp2pgsql because I noticed the liblwgeom.dll had an SFCGAL
> dependency and I didn't want these executables which had NO REASON
> whatsoever of needing SFCGAL being infected by this cause it made them much
> less portable.

This is going at cross purposes to sanity and security.  packaging
systems object, and you have already noticed debian fixing this sort of
thing.

> Darafei asked why I prefer static linking liblwgeom and my reason I
> mentioned is NOT just because I build for windows.

I'm not so sure :-)

> In the case of liblwgeom, there is always a version of liblwgeom with each
> PostGIS, intended to be used JUST for that version of PostGIS.
> So you aren't gaining any security benefits or performance improvements as
> you would by having a dynamically linked GEOS / GDAL/ or SFCGAL.

That's true.  But if it's actually a library, then following norms is
less likely to run into unexpected behavior.

> You SHOULD always be compiling these together as a unit to prevent
> unexpected behavior.

Yes.  But that means that if one is namespaced, the other should be too.

> So reasoning of why packagers normally dynamically link "I want to be able
> to apply a security update or performance enhancments without having to
> recompile all packages that depend on X" , doesn't hold water here.

That's true for lwgeom being included in postgis.   It is NOT true for
anything lwgeom or postgis depends on (geos, sfcgal, proj, or anything
else).  Having something that is actually a dependency be hidden is a
serious bug, and is asking for special treatment from others, and taking
up their brain time.


It strikes me that the real issue is a combination of

  wanting to install  postgis simultaneously for multiple pgsql and
  multiple postgis versions

  not having a design for accomodating that

A good design would ensure that all things installed are versioned, both
by pgsql version and by postgis version.  That includes command-line
tools and headers as well as libraries.  So that means not putting
liblwgeom in ${PREFIX}/lib at all, or calling it
liblwgeom-pgsql95-postgis25 (before the shlib version!).  It seems best
to put it in a named directory.

The other approach is to prohibit multiple installations.  Anything in
between full namespacing and allowing only one is just going to be
trouble.