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

[Sebastiaan Couwenberg]

On 10/01/2017 01:20 AM, Regina Obe wrote:
>> 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 think it was just my misunderstanding of how Linux packages interrelate.
> 
> I was thinking about Ubuntu and Centos.
> 
> For example I have this Ubuntu box (which is old 14.04 (not old by strk's standards :) ) ) and it's running this:

If a distribution is more than two years old, I consider it old too.
It's no longer the latest Debian stable/Ubuntu LTS release.

> POSTGIS="2.3.3 r15473" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.11.2, released 2015/02/10" LIBXML="2.9.1" LIBJSON="0.11.99" RASTER
> 
> And PostgreSQL 9.6 version 
> 
> PostgreSQL 9.6.5 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4, 64-bit
> 
> I had upgraded it using apt.postgresql.org
> 
> But I think postgresql.org relegates other dependencies to the Ubuntu project.
> 
> I don't have handy at moment, but I saw similar with an old Centos I was trying to help someone with.
> Which I updated with yum.postgresql.org
> 
> Devrim (who does the yum.postgresql.org packaging) relies on EPEL so that means even if he ships a PostgreSQL 9.6 to older platforms, he is stuck with what he gets from EPEL.
> 
> So a newer Centos would have newer stuff like newer GDAL and old Centos would have like GDAL 1.11 etc.

Exactly. This is just the nature a enterprise distributions. Packages
don't get updated to newer releases during the lifetime of the
distribution (only targeted bugfixes get applied).

> But I presume Ubuntu has unstable ports similar to Debian where you could get newer things if ABI compatibility is kept. 

Ubuntu has backports like Debian does, but Ubuntu doesn't have someone
actively maintaining geospatial packages like Debian does.

Core libraries like GEOS, GDAL and friends are not good candidates for
backports, because whenever they break their ABI all packages depending
on these libraries need to be rebuilt. That kind of change is too
invasive for stable releases.

The UbuntuGIS PPA does include newer releases of GEOS, GDAL and friends
(but not all their reverse dependencies) for Ubuntu LTS releases. But
the project suffers for a lack of contributors, it mostly gets
new/updated packages from OSGeo-Live. Ubuntu users also tend to combine
the UbuntuGIS PPA with the qgis.org repository and suffer from the lack
of coordination between the repositories, causing the packages not to be
intergrated properly (e.g. qgis.org packages not getting rebuilt
immediately after gdal or grass updates in ubuntugis-unstable).

> But then I don't know what happens with PostgreSQL because even with ABI compatibility since we now check these at compile time and disable features of GEOS.
> If you compile with a lower GEOS, but you are shipping to a user who has upped their GEOS via unstable or something, the user is only getting the stability and speed improvements and not newer functionality that PostGIS would provide.

The {yum,apt}.postgresql.org repositories are yet another 3rd party
repository, that cannot integrate will all other popular 3rd party
repositories (integration is what distributions do). It could perhaps
offer an ubuntugis variant like qgis.org does, to have newer postgresql
packages built with the newer packages in the UbuntuGIS PPA. I think
this will be unlikely though, as the pgApt project does not have
abundant manpower either.

> I guess that's okay since if they tried to use any of those functions, it would throw (compiled with lower than GEOS 3.6) .
> Just makes me think about scenarios I never gave much thought to before.
> 
> 
>> 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.
> 
> I had in the back of my mind a problem like that.  It's a similar issue I think that affects OSGeo projects.  
> So even with funding there doesn't seem to be a fair way to divvy up that money unless it's the packager/contributor 
> initiating the request and ear-marking it for a particular task.
> 
> Or compensating via non-monetary ways.

Sponsoring travel and accommodation to sprints is a great way to reward
contributors. Having a week or so to focus on specific tasks greatly
helps to get things done that don't fit well into the free time
available to contributors.

Kind Regards,

Bas

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