[postgis-devel] postgis extension sans raster (only for folks who can't compile with raster support) - PSC Vote and developer/packager comments please

[Paragon Corporation]

Bborie,

 

The issue is as I understand it is he doesn't package GDAL so he gets it from upstream and upstream GDAL compiles in QT to support other GFOSS.  

So to install PostGIS you have to end up installing those other things which then causes internal conflicts or you might not even have GDAL if your OS is too old.

 

I think Devrim (yum.postgresql.org guy) expressed the same for older OS he supports that he relies on GDAL from upstream.  Which is why he can't package PostGIS raster with CentOS 5 and has been apologetic for it that he can't offer the same extension support for that as he does for newer systems.

 

Doing this will also help those CentOS 5 folks out so they can at least do 

 

CREATE EXTENSION postgis;

 

Like everyone else.

 

Yet another reason why I don't want liblwgeom to be a system thing that PostGIS has to rely on.

 

Thanks,

Regina

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Bborie Park
Sent: Saturday, October 24, 2015 2:20 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] postgis extension sans raster (only for folks who can't compile with raster support) - PSC Vote and developer/packager comments please

 

The raster component doesn't require QT, so there is something else amiss in FreeBSD.

 

I'm indifferent but I'll admit that I compile everything myself for all my use-cases of PostGIS as every package built for Ubuntu (12.04, 14.04) cause me issues in the end.

 

+0

 

-bborie

 

On Sat, Oct 24, 2015 at 11:14 AM, Paragon Corporation <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

One FreeBSD packager brought up that they can't compile PostGIS with raster
support because of the QT dependency it drags in among others.  I still
don't quite understand why that's a big deal.

Anyway people complain because then they can't install postgis with

CREATE EXTENSION postgis;


Like everyone else.  I've seen similar complaints with Homebrew folks who
compile their own.

Rather than splitting raster out of postgis as many have proposed and
causing an upgrade mess for everybody , I propose this:

https://trac.osgeo.org/postgis/ticket/3338

In a nutshell: encode the lack of raster in the postgis version number
rather than the extension name itself.  This approach has the following
benefits (repeated from the ticket):
We still have raster as the default behavior and people still need to say
explicitly without-raster during configure.


1)    Most extensions that rely on PostGIS just use the vector portion, so
keeping the name the same they can continue on without having to change
their requires statement (changing requires is huge mess particularly for
extensions like pgRouting since then they'd have a different requires for
new PostGIS than older and they support 3 versions of each PostGIS minor)

Not to mention a huge mess for all the documentation already out there.

 2)   We have the same set of instructions for everybody:

CREATE EXTENSION postgis;


3)    With the version differentiator it's trivial to upgrade a half-baked
version 2.3.0-no-raster to a full yummy 2.3.0 version. We just add upgrade
scripts to go from 2.3.0-no-raster to 2.3.0 regular postgis  (which is
pretty trivial exercise)

4)    Similarly we can have a 2.3.0--2.3.0-no-raster that gets installed if
you compile without raster support. Which will drop all the raster functions
during the upgrade.

5)    It's fairly trivial to do compared to returning not supported I was
thinking of before.


What do folks think about this? Am I nuts or is this a great idea?

If all are for it, I'm willing to do the work to make it happen for 2.3.0

Thanks,
Regina




_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
http://lists.osgeo.org/mailman/listinfo/postgis-devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20151024/25bb174a/attachment.html>