> I meant with 4 instead of 1. > postgis-raster-topology > postgis-noraster-topology > postgis-raster-notopology > postgis-noraster-notopology
Regardless how you dice it, option 1 or 2 you still have the same headache without manually copying files. a) a PostGIS that offers all modes - postgis, topology, sfcgal, tiger geocoder, address standardizer or b) Breaking up at package level postgis_core postgis_raster postgis_sfcgal For most packagers I would suggest not even bothering with this, build everything as you are doing and let users decide which extensions they want in their database CREATE EXENSION ...; Breaking out postgis_topology and postgis_tiger_geocoder from core is actually kinda a silly cause they don't add any extra dependencies That's just strk's conflating system packaging with PostgreSQL extension packaging (neither of which he respects) I had only entertained this idea because I know people who build their own were having some problems with getting GDAL and it will be harder for users on older platforms. So I figured half an extension which other extensions can say "okay you're postgis enough" for me to say you satisfy my "depends on postgis requirement" BTW I think this was the big fight we had last time why we never went anywhere. Stalemate. If we break postgis _raster out into a separate extension, it will be really hard to put it back if we are wrong and they'll be a lot of distrust from people because we changed the rules on people in a minor release. With option 2 -- it's easy to move to option 1 later at PostGIS 3 when people are prepped for big breaking changes and when the PostgreSQL extension machinery is more flexible to handle things like A variable that you can use to target what schema you dependent extension is installed in. Thanks, Regina _______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/postgis-users
