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

[Paul Ramsey]

> On Nov 28, 2018, at 9:36 AM, Greg Troxel <gdt at lexort.com> wrote:
> 
> 
> "Regina Obe" <lr at pcorp.us <mailto:lr at pcorp.us>> writes:
> 
>>> If it's used semantically like a library -- which it really seems to be
>>> -- you should allow dynamic linking within the build.  You are kludging
>> around
>>> lack of a design for managing multiple versions, and adding more
>>> maintenance headaches.  So -1 from me, which I realize doesn't really
>> count.
>>> 
>> [Regina Obe] 
>> Not sure what you mean by used like a library.  
>> The original reason why we had it segmented was because it was easier to
>> test that way via CUNIT.
>> Then later this segmentation proved a little useful when we introduced
>> raster.
>> 
>> To me it's more a header only library that can be detached from Postgres for
>> ease of testing.
>> 
>> To me it's just a pile of shared code across the different extensions
>> postgis/ postgis sfcgal / postgis raster / postgis topology
> 
> That's the definition of a library :-)

It’s a library that ONLY WE USE. And that we DO NOT want anyone else to use. We broke out the code for our purposes, it lets us do things like c-level debugging without firing up a backend, and valgrinding without fighting the postgresql memory manager. The point was never to share with others. Using the word “library” seems to make people want to install it in system locations (to the extent that the Debian packagers stripped away our default of statically linking it to the postgis.so module) and invite others in to play, and we do NOT want that. Is there a different word we can use?

P.

> 
>> And in fact like I said each piece only uses bits of it -- thus it's a pile
>> of code. 
> 
> That is also part of what library means.
> 
>> postgis will not need it bound to sfcgal, but will need it bound to GEOS
>> SFCGAL needs a variant that includes SFCGAL hooks
>> postgis topology needs it only bound to GEOS
>> postgis raster doesn't need the GEOS part at all.
> 
> In the modern world where almost all use of any successful program is
> via packaging systems, having other parts of postgis also depend
> (theoretically unnecessarily) on things that other parts actually depend
> on does not hurt.
> 
> As I see it you are railing against established software norms because
> postgis is trying to support multiple installations without really
> having a plan.
> 
> (ok on your opininon that rtopo not being viable in postgis - just
> seemed worth bringing up)
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/postgis-devel <https://lists.osgeo.org/mailman/listinfo/postgis-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181128/039ceeda/attachment-0001.html>