| 1 | | 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. |
| | 1 | 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. |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | 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. |
| | 6 | |
| | 7 | So my proposition is as follows: |
| | 8 | |
| | 9 | --without-raster |
| | 10 | |
| | 11 | Perhaps --without-geos |
| | 12 | |
| | 13 | |
| | 14 | 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) |
| | 15 | |
| | 16 | |
| | 17 | {{{ |
| | 18 | CREATE EXTENSION postgis; |
| | 19 | }}} |
| | 20 | |
| | 21 | |
| | 22 | 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. |
| | 23 | |
| | 24 | So a full version can explicitly ask for the lesser version |
| | 25 | |
| | 26 | |
| | 27 | {{{ |
| | 28 | CREATE EXTENSION postgis VERSION "2.5.0less"; |
| | 29 | }}} |
| | 30 | |
| | 31 | And users who want to upgrade from the lesser to the full version can do so |
| | 32 | Packagers if they do want to provide both options, can override the installed control file |
| | 33 | so their postgis_core would have a postgis.control file that has "2.5.0less" |
| | 34 | |
| | 35 | and the full postgis would overwrite the postgis.control file with "2.5.0" |
| | 36 | |
| | 37 | Having both you can explicitly ask for the lesser by |
| | 38 | |
| | 39 | {{{ |
| | 40 | ALTER EXTENSION postgis UPDATE "2.5.0less"; |
| | 41 | }}} |
| | 42 | |
| | 43 | Only thing is what to call this new version, less, lite, core come to mind. |
| | 44 | |
| | 45 | 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. |
| | 46 | 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. |
