"Regina Obe" <l...@pcorp.us> writes: >>>> The proposals are: >>> >>> 1) Move raster to its own extension "postgis_raster" >>> See https://trac.osgeo.org/postgis/ticket/3888 > >> this gets us two extensions, and if we split into N, we will have N >> extensions. > > Greg I'm missing something here. If you go with this option you still have > 2^N and a dependency wreck. > > Because the full PostGIS would still have to ship the same number of > extension scripts even with the postgis_raster broken out. > Don't confuse packaging with the way the PostgreSQL extension model is set > up, they are not the same.
What I meant is that instead of assuming raster or no raster, let's assume that besides the core we have 4 options. So then we would have to build 16 versions of postgis, instead of core and 4 extensions. I wasn't even thinking about upgrade scripts. > And people who insist on compiling without raster support just have to use > scripts as they always have had to. But is it necessary to talk about "compiling without raster support", vs "raster support not loaded"? From the packaging viewpoint, I don't like options in how things are built, just subsets of installing. >>> 2) Provide two versions of extension "postgis" >>> See https://trac.osgeo.org/postgis/ticket/3890 >> If we split into N, we will end up with 2^N. >> >> I think 2^N is untenable, and option 1 is therefore the only reasonable >> choice. > > Again it's not the same and you efforts in packaging are exactly the same. > > If you wanted to create two distinct packages, you'd either copy select > files or you would compile postgis twice, once with raster and once without. > It's the same story without option 1 or 2. I meant with 4 instead of 1. postgis-raster-topology postgis-noraster-topology postgis-raster-notopology postgis-noraster-notopology
signature.asc
Description: PGP signature
_______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/postgis-users
