[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]

Greg,

1) I was thinking it was more of a benefit for folks who have to compile their own who don't need raster but REALLY want to install with PostgreSQL extension machinery or package maintainers who absolutely can't compile with GDAL for some reason or another (e.g. too old of a platform or dependency hell issues)
2) Given that most packagers build with GDAL already and it's not unimaginable we won't want to use GDAL in the future for vector support, I think breaking  raster out of postgis just to appease those folks who can't compile with GDAL is a big pain for everybody  with no real upside gain.
3) Since no one has spoken up that brought this up as an issue -- except for strk -- who hates extensions anyway.  Seems there is not enough of a desire for this to put in the effort.


Given your comments, I've retracted my request and marked the ticket as wont fix.

Thanks,
Regina

-----Original Message-----
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Greg Troxel
Sent: Tuesday, October 27, 2015 8:59 AM
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


>From my viewpoint (as a packager), it causes problems to have something with a particular name be different.  Lots of upstream distributions have a notion of optional components and configure differently depending on whether other packages are present.  This is only really useful for people compiling by hand.  For a package, the packager has to decide what is required and what isn't, and express a dependency on the required packages, which forces them to be built/installed first.  Then, anything else that happens to be installed is either hidden by the packaging system or configured off, to get a reproducible build.

Having options forces the packager to make a decision whether to include them or not.  The question is about whether everyone should incur the pain of the dependency, how useful the feature is, and how hard it is to get it separately.  (pkgsrc does have the notion of options, but binary package users get the defaults.)

I don't see that requiring gdal is all that big a deal, given that we are already depending on geos and postgresql.  If there is an issue, it may be best addressed by having people packaging gdal splitting off some of the things that cause it to get really big.  (How many people out there are using postgis, but not doing enough other random geo stuff to not have gdal anyway?)  In pkgsrc I have just made gdal a non-optional dependency of postgis, and I am not even considerating changing it.

So, from my point of view, postgis needs to decide if raster is part of postgis, or a separate option.  If it's part of postgis, then gdal becomes a non-optional part of the build.  If it's not part of postgis, then it should be somehow buildable separately (assuming postgis is already installed, probably) so it can be a separate package.

I would find it awkward to have two things named postgis that do and don't have raster.  So if raster is to be split, I would take the pain now and use the extension name postgis_raster or something, and let postgis be the non-raster version.