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

[Greg Troxel]

"Regina Obe" <lr at pcorp.us> writes:

>>On 09/29/2017 06:28 PM, Darafei "Kom?pa" Praliaskouski wrote:
>>> Please don't hesitate to raise minimum versions to latest released at 
>>> the time of release.
>>> If someone needs an older version, they are free to comment out the 
>>> checks and build at their own risk.
>>> Otherwise we're going to have distros with older versions of 
>>> libraries, because "it's not required to upgrade so let's not".
>
>> Or distributions are forced to stick to older versions of the
>> libraries because the newer versions cannot be integrated properly
>> with all their reverse dependencies. As is currently the case for
>> GEOS >= 3.6.
>
> That's why I'm not pushing GEOS >= 3.6.  I know that packagers at
> least in past had issue with upgrading GEOS 3.6 because of osm2pgsql
> referencing c++ apis instead of geos c-api.
> Though I thought that issue was resolved since.  Perhaps not.

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.

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.

> 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.

> 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 :-)

> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170930/e052b4bd/attachment.sig>