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

[Darafei "Komяpa" Praliaskouski]

To push libraries to get update, either:
 - make downstream packages dependencies tighter (with each PostGIS release
depend on current minor of GEOS);
 - report a CVE / security bug, so that it's handled by security team (can
become just a three-line backpatch though).

On Thu, Jan 24, 2019 at 2:14 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> 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
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel



-- 
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20190124/3cac4f73/attachment.html>