Allow having a postgis extension even when have --without-raster used in configure

[giohappy]

Make inside extenstions/postgis tries to execute the targets from rt stuff even if —without-raster was set for ./configure

[robe]

You can't make postgis extension without raster included because then it wouldn't be the same extension. We decided on this a long time ago.

Now I'm willing to entertain the idea of having an extension that is not called postgis.

something like postgis_core so it's clear it doesn't have raster in it.

Others didn't like that idea. Anyrate it's not something we are going to do in PostGIS 2.4, might be a reconsideration for PostGIS 2.5.

[giohappy]

Ah ok Sandro. —without-raster made me think the postgis extensiob could have been without rasters.

[robe]

giohappy it could have been a while ago, now it's really hard to change and less reason now that most are building with GDAL.

BTW this is Regina not Sandro. Build/upgrade/install tickets automatically get assigned to Sandro.

[robe]

I'm reopening this, we've been talking aobut the possiblity of having an extension without raster and encoding that in the version number. Something also will be the possibility of disabling all GEOS functions if a new feature —without-geos is specified. Both are on the table and I'm planning to make a motion vote about it.

[robe]

original discussion here - ​https://lists.osgeo.org/pipermail/postgis-devel/2012-January/thread.html#17147

[giohappy]

Ok so —without-raster is just useful to build for example the lwgeom lib, otherwise I don't see why it's there.

[robe]

giohappy it is also useful to be able to install postgis. Just means you have to use scripts to install instead of CREATE EXTENSION which actually is much of what our test plumbing still does.

At the time we made this decision many people didn't believe the CREATE EXTENSION feature would fly true it had some early warts which are getting and better with each passing. CREATE EXTENSION was at its infancy and many long using postgis folks didn't trust this black magic. So having a new feature CREATE EXTENSION tied to a new feature raster that we wanted to show-case and make it easy for folks to use was the best thing to do. I still feel it was the best thing to do, but I think after much thought that we can still offer a CREATE EXTENSION postgis for folks who want to explicitly opt-out of raster without breaking backward-compatibility.

[giohappy]

I agree that having the option to use CREATE EXTENSION without raster would be useful. Many deployments don't need the raster part of PostGIS. Anyway I respect the past decisions and I don't want to stress this too much.

[komzpa]

I don't use raster much, maybe once or twice in my life. It goes packaged and dragged into Docker containers that could have been much smaller if they wouldn't depend on raster. Raster drags in GDAL, and GDAL drags in lots of different things.

It's possible to build —without-raster, so it's not a complete showstopper, it just requires manual labour. With raster being split out, it's possible to have say two debian packages, one with "geometry" postgis and one with "postgis_raster", that will drag in different amount of dependencies.

[robe]

It is messy for debian packages to do that because then they'd have to build the full postgis and then break apart into a postgis raster piece and postgis piece to accomplish what you describe. Then again they seem to package the scripts separately anyway so maybe it wouldn't be that much trouble. They'd still be free to do that with this approach and would just have to package the rtpostgis lib and full postgis—-2.5.0 create scripts in the raster package and have raster depend on their postgis_core package.

However as I mentioned to strk, I think what we call the VERSION "2.5.0" should still have raster in it because it breaks backward compatibility otherwise, what I propose doesn't break backward compatibility but gives more flexibility forward.

What I am proposing is encoding the lack of raster in the version name which is the easiest thing to do. I wanted to call this version "2.5.0less" because it's not clear how much less it is than what we have. If we go with proposing the —without-geos, less might be much less than core as a ton of our functions will be stubbed with error messages.

So my proposition is as follows:

—without-raster

Perhaps —without-geos

would give you a postgis extension of version something like "2.5.0less" or "2.5.0lite" or "2.5.0core" whatever we wish to call the thing and that would be the default for you and what you get when you run (the default is encoded in the postgis.control file)

CREATE EXTENSION postgis;

If you compile without specifying without-raster, you'd get what we get now, but the VERSION 2.5.0less script would still be created for you to use.

So a full version can explicitly ask for the lesser version

CREATE EXTENSION postgis VERSION "2.5.0less";

And users who want to upgrade from the lesser to the full version can do so Packagers if they do want to provide both options, can override the installed control file so their postgis_core would have a postgis.control file that has "2.5.0less"

and the full postgis would overwrite the postgis.control file with "2.5.0"

Having both you can explicitly ask for the lesser by

ALTER EXTENSION postgis UPDATE "2.5.0less";

Only thing is what to call this new version, less, lite, core come to mind.

I've often wished GDAL was a true plug-in architecture that the libgdal only loaded the extra libs at runtime like it can do with proj, without explicitly embdedding the symbols of the lib in it. I asked Even about that a while ago and he said it would be a ton of work so probably not doable. GDAL itself is not that heavy. I build with only a couple extra dependencies (Curl, SQLite, Expat, and OpenJPEG) and my GDAL 2.2.2 lib is only 13MB and each extra depen adds about 500kb to 1 MB each.

[komzpa]

If .so files are different, it's possible.

It was for sfcgal: it depended on OpenSceneGraph and it pulled in a lot (hundreds of megs) of dependencies. Now (I see it in Ubuntu Artful at least) it's split up into libsfcgal-osg1 that's optional, and libsfcgal1 that doesn't depend on OpenSceneGraph.

Single source package can produce several binary ones.

[robe]

komzpa yah thinking about it more, I don't think it would be too difficult for packagers to separate the two.

They would compile regular old way, but when packaging

put all the rtpostgis, and full postgis scripts in the postgis package.

Have a postgis_core package that leaves out the rtpostgis and full postgis scripts — just has the —-2.5.0lite/less/core/whatever we call it scripts.

Have the full postgis install that depends on postgis_core.

As I recall the postgis package is really the package to install the commandline tools, but it depends on postgis-2.4.0 or some such thing which gasp depends on PostgreSQL server. Which is annoying since there is no way to just install the raster2pgsql, shp2pgsql without installing the whole shebang, unless I missed something.

Best I could propose was this - ​https://gist.github.com/robe2/6676c33b745621e450adf23e92de986b

[strk]

FYI: I've pushed an experimental branch splitting raster out of "postgis" function here: ​https://git.osgeo.org/gogs/postgis/postgis/pulls/18

It does not deal with upgrades from 2.4.x or earlier yet but I have a plan for that: unpackage raster and warn user about needing to create postgis_raster from unpackaged.

[giohappy]

Great! That's what I was hoping

[strk]

Great, I hope you'll be willing to help with implementation, tests and documentation

[robe]

giohappy strk says he's done with his first draft. Please test his pull request. komzpa you too since you both lobbied for this.

[giohappy]

Thanks. I'll test as soon as possible.

[strk]

Plese report in #3888

[robe]

Counter proposal to #3888 to achieve the same objective is in #3890

I am going to close this now as it has been superceded by #3888 and #3890

[Mike Taves]

Also duplicate of #1713 from 6 years ago