[postgis-devel] PostGIS 2.5 what should be minimum requirements?

[Regina Obe]

> There isn't agreement about whether it is a bug for packages to use the
GEOS C++ API.  If it really is a bug, GEOS is buggy for installing the
headers.
I'll let strk address this one.  

> The osm2pgsql issue is not resolved.  There is code committed to stop
using geos entirely.  However, there is not yet a release, so the issue is
not resolved.  I see now that there an RC was published 12 days ago.
Okay so it may be possible to make the requirement 3.6 then.  I didn't
because I knew most package maintainers were shipping 3.5 and we only have I
think 3 functions not widely used yet that rely on 3.6.

I'm fortunate in that I ship most of full stack with PostGIS windows and I
know it will only be used under PostgreSQL because it's localized so I can
completely control most of the dependencies without concern.

>> GDAL.  Greg Troxel mentioned for example his build crashed with lower 
>> GDAL (I think it was a pre-2.0, but was fine with GDAL 2.1 ).

> With GDAL 2.0.3, the postgis 2.4 RC passes tests.  With 2.1 and 2.2, the
> raster tests provoke a crash.   I have not yet debugged this.

Which 2.1 and 2.2 were you testing with.  Last test I did was with just
released GDAL 2.2.2

The bots we have have tested against GDAL 2.1 and 2.2 head, but they build
with very minimum dependencies.  Debbie builds with none aside from the
python ones
Winnie builds with what people asked and were willing to pay for me to
package and no none-opensource ones.
So that's just SQLite, OpenJpeg and whatever GDAL provides out of the box.

I recall someone ticketing an issue with GDAL on PostGIS crashing and it
only happened when he was running in a VM  
I can't remember the ticket.  I told him to increase his memory and that
fixed his issue.  He was running I think 2 GB in a docker image.
The issue turned out to be I think the NetCDF driver that when it was
loading it was allocating memory and just enough to make things crash.
He wasn't even using NetCDF but it still needed to allocate memory to load
the libraries I guess.


>> I'm also appalled that a lot of Linux distros are still running GDAL
>> 1.* but I suspect that's because of the many reverse dependencies you 
>> mentioned to keep happy.

> Generally if more than one packaging system hasn't update that's a clue
that there are good reasons :-)
Agree though once osm2pgsql has been released, perhaps we can revisit in a
month or so and bump GEOS to 3.6
There aren't all that many functions that rely on GEOS 3.6, so I'm not that
adamant about bumping it
and I think most of the stability stuff is backported to GEOS 3.5.

GEOS 3.8 might be a real game changer though, but that is too far out for us
to require it.
I think Dan Baston had some plans about precision modeling stuff (which I
think requires changes to GEOS)
and Mat in 3.7 made  C++ 11 a requirement GCC 4.8.1+ I believe is required. 
He will really start making use of them in 3.8 to streamline GEOS code.

>> I'm pretty concerned about this as I feel packagers are under 
>> appreciated.  It would be nice if we can come up with some way to fund 
>> some of these efforts.  That would both help all projects and minimize 
>> on packagers getting burned out.  But that's a topic for another day.

> The thing that would really help is upstreams 1) being more careful about
API and ABI compat and 2) ensuring that there are releases (actual releases,
not code in git) that work with the most recent releases of all
dependencies.  Packaging software with normal build systems that doesn't
have extra issues is not so hard.

Will keep that in mind.  Would be helpful to have packagers more engaged in
what we are doing
You, Baz, and Devrim have been really helpful in that regard and I
appreciate that a lot.

Thanks,
Regina