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

Sat Sep 30 09:08:59 PDT 2017

On 09/30/2017 04:19 PM, Greg Troxel wrote:
> "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.

It is not a bug to use the C++ API, it is just inconsiderate towards
users and packagers who need to deal with the increased complexity of
GEOS updates.

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

In Debian we still have OSSIM 1.8.20-3 as a blocker, OSSIM 2.0.0 & 2.1.0
have finally been released recently but contain issues that make it
unsuitable for inclusion in Debian [0]. The next release should resolve
those issues, but due to the lack of a public roadmap there is no
telling when we can expect the release. After the release OTB will need
to be updated to work with the new OSSIM so that it can be moved to
unstable, and the GEOS transition can be set in motion.

[0] https://lists.debian.org/debian-gis/2017/08/msg00008.html

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

GDAL 2.x is still fairly recent, it's not surprising that not all
distributions have adopted it yet as they haven't made a new release
since then. The enterprise distributions (and EPEL) are in the same boat
as Debian stable and cannot introduce such a major change after their
release. The latest Fedora has GDAL 2.x, so it will find its way into
EPEL for RHEL/CentOS 8.

Due to unfortunate timing and nobody contributing to the maintenance of
the geospatial packages in Ubuntu, GDAL 2.x didn't make into Ubuntu
xenial even though it was available at the time. But like EPEL, it will
be included in the next LTS.

Regina, which Linux distributions are you talking about exactly? I'm not
aware of any that are sticking to GDAL 1.x.

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

Funding packagers is a sensitive subject. In Debian we had the Dunk-Tank
fiasco where some contributors where paid for their work and others
weren't, that inequality was not acceptable to the project members.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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