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 wouldn't be possible to do that for debian packages, they'd still package the thing as postgis and still drag or not drag in those dependencies. Because otherwise the two packages would be in conflict.

[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