[postgis-devel] Can we put back GEOS 3.5 support in 3.0?

[Paul Ramsey]

Well, there’s going to be some exciting news on the GEOS front next week, and hopefully it will bring everyone back to the table :) I don’t know how to break the packaging logjam though, as there’s something about system libraries that defies makes everyone “go slow”. Which isn’t really fair, since we’ve done everything necessary to make things easy: the ABI never changes, there’s never a reason to not just dump the latest GEOS into place. What can we do to convince packagers we are sincere?

P

> On Jan 23, 2019, at 3:05 PM, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> 
> On Wed, 23 Jan 2019 at 23:45, Darafei "Komяpa" Praliaskouski
> <me at komzpa.net> wrote:
>> 
>> I believe that not upgrading GEOS is self supporting problem.
>> 
>> Nobody cares about GEOS, as nobody uses GEOS directly. They use PostGIS, QGIS, or whatevergis that uses GEOS. The only reason to pull a new version is if something can't work with older.
>> 
>> If we, PostGIS developers, are affected by the same plague, we basically can't ever close a ticket in PostGIS GEOS milestone - we're supporting old versions, so you can still get your PostGIS with the bug manifesting itself. A recent case is someone showing on PostGIS IRC asking why ST_Subdivide won't work as expected in their 2.4.latest and the issue was they used unpatched GEOS.
> 
> I'm watching this thread with interest! From a QGIS developer's
> perspective, we're consistently running into this same issue. We've
> got a choice between:
> 
> 1. Fixing bugs and implementing features in GEOS, and then waiting...
> 2? 3? more? years before we can actually rely on users HAVING those
> fixes/features when they install QGIS
> or
> 2. Being "bad" open source citizens and implementing workarounds and
> features downstream, so that users get these changes within (at most)
> 4 months.
> 
> Guess which option we usually pick? ;)
> 
> I'm really happy to see the recent increase in activity on the GEOS
> repo, and the performance boosts and optimizations which are landing
> there. I'd love to see GEOS regain it's rightful place as the
> "standard" geometry processing library used by PostGIS/QGIS/GDAL/R/...
> but... I can't see this happening with the combination of GEOS' slow
> release cycle and (more importantly) the constant demand from users to
> see the latest versions of applications (PostGIS, QGIS, etc) available
> on these ultra-slow distributions, with outdated library versions.
> 
> One of these days I'm going to propose that QGIS just bundles the
> whole of the latest GEOS stable release inside the QGIS repo (maybe as
> a git submodule) so that we're guaranteed to have the very latest GEOS
> release alongside QGIS. It's honestly the only way forward that I can
> see working. Maybe PostGIS should consider the same...
> 
> Nyall
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel