[postgis-devel] PSC Vote: Stop installing liblwgeom INCLUDES in system

[Regina Obe]

> [I hope this still remains  on the good side of the helpful/annoying
line...]
> 
[Regina Obe] Still on the good side of helpful the annoying line is
debateable, it does at very least cause me to think more about this, which I
guess is good.

> 
> There are three separate problems with big dependencies:
> 
> 1) if they don't build the entire package is broken
> 
> 2) it can take a long time to build them
> 
> 3) people installing binary packages have to install them
> 
> to me, #3 is generally the least serious of these, unless it's some small
> program needing qt5.  But I realize others and other systems see it
differently.
>

I'll start with my issues with dynamically linking liblwgeom.  Main issue is
liblwgeom as pramsey explained before, exists SOLELY so we can test the
little bullet that is part of all the postgis extensions without having to
drag big elephant PostgreSQL into the room.

In addition and perhaps this is an implementation annoyance that we can fix
-- when this bag of bullet code is compiled into a library, it drags in
dependency on GEOS, CGAL, Boost, SFCGAL.
strangley no dependency on GDAL (which maybe we can learn something from how
we have setup raster), if you CHOOSE to compile the big bag of stuff we call
"POSTGIS".

So when this tiny bullet of code is statically linked - the bits that raster
doesn't need (GEOS / SFCGAL) (at least on my system) , are left out of the
resulting postgis_raster.so.  Granted well raster needs postgis and postgis
needs GEOS so well that bit is a wash.

For postgis_sfcgal -- I think it drags in SFCGAL/CGAL/Boost but no GEOS -
again sunk cause postgis_sfcgal has a dependency on postgis in the database.

For postgis_topology /postgis -- there ends up just being a dependency on
GEOS.

Now what gets interesting is the commandline tools -- many packagers seem to
package these as separate from postgis
Though oddly postgis-gui for some god awful reason (partly of our own doing)
has a dependency on PostGIS which means you need PostgreSQL installed as
well even though you have a machine dedicated to loading.  Minor for some a
huge annoyance for many especially those on docker.

shp2pgsql/pgsql2shp should really have no dependency on SFCGAL or GEOS (well
GEOS I have to check)  and they don't if statically linked to the liblwgeom
bullet.

raster2pgsql should only have a dependency on GDAL (in fact one could argue
this doesn't belong in PostGIS at all and this code should be plugged into
GDAL and the postgis raster driver in GDAL will have read/write capability.
But forget I said that, since it serves me to have it this way so I don't
have to compile GDAL with PostgreSQL support and can use the same GDAL
across  all versions of my distributions.

pgsql2shp and shp2pgsql-gui both have a dependency on PostgreSQL (but really
only libpq, so in theory we can change our configure to allow building these
with just libpq dev) and frankly most people don't even need these.


-- So anyway the other changes I'd like to see happen realizing that
packagers are bundling the gui separately but are being forced to have it
depend on PostGIS is to allow it to compile
Without postgis.  I guess this one should happen too before alpha

In that case if you have nothing you should be able to compile shp2pgsql,
raster2pgsql 
If you have PostgreSQL dev or libpq, then you can also compile pgsql2shp,
shp2pgsql-gui.

Thus going back to our static model of liblwgeom not living on its own,
cause it's a bullet (and should only be used in our extension and commanline
approved guns).
Means that packagers can continue to package load tools separately, still
provide raster and sfcgal, without the added dependency of things not needed
when people just want the tools.


> But, if sfcgal is judged to be too heavy (relative to a system which is
already
> running postgresql and has geos, which means it's fairly big and can
handle
> C++11), maybe we should rethink using it in the first place.
> 
[Regina Obe] 
I find postgis sfcgal very useful, so I don't want to get rid of it.  I
think a lot of people do.  It's got some really useful functions even for 2D

that postgis / geos doesn't and it has great support for some 3D stuff.

For windows packaging it really doesn't hurt me much cause I have boost/CGAL
dependency with pgRouting
And SFCGAL by itself after those is not a huge deal and I ship an all or
nothing package.  It's however convenient that if you need to make a little
loader package
You can copy the few libraries needed on a disk and be done, since there is
no standalone liblwgeom to drag in dependencies you don't need.

On some other platforms e.g. debian where they include SFCGAL along with the
GUI side of SFCGAL that pulls in OpenScene Graph.
It becomes more of a concern.  I'm not sure if the actual sfcgal lib has
dependency on open scene graph, so that might be just the gui part, but I
have heard people complain about getting like a kitchen sink of
OpenSceneGraph when all they wanted was PostGIS.

Since a dynamical liblwgeom relies on SFGCAL, it is not possible to create
multiple packages that won't break something as in the end you'd need one
great liblwgeom to rule them all if you want a dynamic liblwgeom.


> > From a packaging perspective you can break up the postgis package much
> > more easily if you don't have these needless dependencies.
> 
> If one can build separate pieces with separate builds, as if they are
separate
> packages, then these things become less serious.  
> But that doesn't seem to be
> the case here.  Basically, I see "you must install all the dependencies to
build,
> and then you can split them" as not really addressing the big issues.
[Regina Obe] 
No you don't need to install all dependencies to build.  Right now you can
Compile install postgis without raster without sfcgal  and your liblwgeom
doesn't depend on anything but GEOS.
The only dependency that is not optional (which one can argue can be) is
PostgreSQL itself.  I'll get to that in a bit.

The problem is that liblwgeom you've got there is NOT the same liblwgeom I
get when I compile PostGIS with everything.

They are incompatible liblwgeom's they've got the same .sos version etc, but
one will work for postgis_sfcgal and one will break postgis_sfcgal.

Greg - for you like you said it doesn't matter cause you are dealing with
source packaging, but for binary packaging, this becomes a bummer.

So it annoys me immensely that I've got the same library floating around
that claims to be the same as my brother's but has different dependencies.
And yes GDAL has the same issues which - don't get me started on that one.
That's why a lot of folks statically compile their GDAL.


> 
 [Regina Obe] 
postgis_topology, postgis_raster, and postgis_sfcgal WILL always have a
dependence on postgis itself.
They have both a binary and in PostgreSQL dependency.

So you are always building postgis.
 postgis_topology we throw in there too cause it has no additional
dependencies besides what postgis already has.

postgis_raster brings in GDAL dependency which brings in (1000 more if you
are on a platform that gives you the kitchen sink of GDAL).


Compare that to pgRouting, which has no binary dependency but has a in
PostgreSQL dependency.
So that's why it mostly never makes sense to fold pgRouting into PostGIS
which was discussed a couple of years back.



> > Whether packagers do that or not they are free to decide just as they
> > are free to decide what bits of PostGIS they want to compile.
> 
> Sure, but there is an obligation to users to package it the way it should
be,
> which does get tricky with big optional depenencies.
[Regina Obe] 

Agreed tricky.  You can never fully satisfy everyone.  Which is why we
refuse to give up the GEOS dependency though Darafei would love us too.