<div dir="ltr">The raster component doesn't require QT, so there is something else amiss in FreeBSD.<div><br></div><div>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.</div><div><br></div><div>+0</div><div><br></div><div>-bborie</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 24, 2015 at 11:14 AM, Paragon Corporation <span dir="ltr"><<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One FreeBSD packager brought up that they can't compile PostGIS with raster<br>
support because of the QT dependency it drags in among others.  I still<br>
don't quite understand why that's a big deal.<br>
<br>
Anyway people complain because then they can't install postgis with<br>
<br>
CREATE EXTENSION postgis;<br>
<br>
<br>
Like everyone else.  I've seen similar complaints with Homebrew folks who<br>
compile their own.<br>
<br>
Rather than splitting raster out of postgis as many have proposed and<br>
causing an upgrade mess for everybody , I propose this:<br>
<br>
<a href="https://trac.osgeo.org/postgis/ticket/3338" rel="noreferrer" target="_blank">https://trac.osgeo.org/postgis/ticket/3338</a><br>
<br>
In a nutshell: encode the lack of raster in the postgis version number<br>
rather than the extension name itself.  This approach has the following<br>
benefits (repeated from the ticket):<br>
We still have raster as the default behavior and people still need to say<br>
explicitly without-raster during configure.<br>
<br>
<br>
1)    Most extensions that rely on PostGIS just use the vector portion, so<br>
keeping the name the same they can continue on without having to change<br>
their requires statement (changing requires is huge mess particularly for<br>
extensions like pgRouting since then they'd have a different requires for<br>
new PostGIS than older and they support 3 versions of each PostGIS minor)<br>
<br>
Not to mention a huge mess for all the documentation already out there.<br>
<br>
 2)   We have the same set of instructions for everybody:<br>
<br>
CREATE EXTENSION postgis;<br>
<br>
<br>
3)    With the version differentiator it's trivial to upgrade a half-baked<br>
version 2.3.0-no-raster to a full yummy 2.3.0 version. We just add upgrade<br>
scripts to go from 2.3.0-no-raster to 2.3.0 regular postgis  (which is<br>
pretty trivial exercise)<br>
<br>
4)    Similarly we can have a 2.3.0--2.3.0-no-raster that gets installed if<br>
you compile without raster support. Which will drop all the raster functions<br>
during the upgrade.<br>
<br>
5)    It's fairly trivial to do compared to returning not supported I was<br>
thinking of before.<br>
<br>
<br>
What do folks think about this? Am I nuts or is this a great idea?<br>
<br>
If all are for it, I'm willing to do the work to make it happen for 2.3.0<br>
<br>
Thanks,<br>
Regina<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div><br></div>