Latest stable postgis version with latest working stable dependencies.

[apjoseph]

In using the 12-3.0 image, I notice when running postgis_full_version that some core dependencies are somewhat ancient:

POSTGIS="3.0.1 ec2a9aa" [EXTENSION] PGSQL="120" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 5.2.0, September 15th, 2018" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.3.1" WAGYU="0.4.3 (Internal)" TOPOLOGY

Yet postgis website says this with respect to 3.0.1:

Best served with PostgreSQL 12.2, GEOS 3.8.0, SFCGAL 1.3.7, GDAL 3.0.4, PROJ 6.3.1, protobuf-c 1.3.3, json-c 0.13.1.

And that documentation is actually out of date since GEOS 3.8.0 has a serious error that actually causes the database to crash when running basic geoprocessing operations like st_pointonsurface() -and so definitely needs to be upgraded to 3.8.1.

Many of the bugs users experience with respect to postgis are actually in GEOS, so I'm wondering if it would make sense to have some concept of a most recent stable reference version with respect to major dependencies. For instance, it doesn't matter much if you upgrade postgis from 3.0.0 to 3.0,1 if GEOS and PROJ are still at versions released all the way back in 2018. This is particularly important since this is a database container where if you find a bug in a dependency and need to upgrade it, you have to copy over potentially 100s of GBs of data to a new fresh new docker container for a relatively minor fix.

Looks like the master version could easily support this since the critical dependencies are being built from source.

[ImreSamu]

now: the other alternative is the postgis/postgis:12-3.0-alpine image .. ( GEOS="3.8.1-CAPI-1.13.3" PROJ="7.0.1" ) it is Alpine 3.12 based

• the upstream postgres docker image has been upgraded to Alpine 3.12 ( ~ 1 week ago )
  • https://pkgs.alpinelinux.org/packages?name=geos&branch=v3.12
  • https://pkgs.alpinelinux.org/packages?name=proj&branch=v3.12

postgres=# select postgis_full_version();
                                                                         postgis_full_version                                                                         
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="3.0.1 0" [EXTENSION] PGSQL="120" GEOS="3.8.1-CAPI-1.13.3" PROJ="7.0.1" LIBXML="2.9.10" LIBJSON="0.14" LIBPROTOBUF="1.3.3" WAGYU="0.4.3 (Internal)" TOPOLOGY
(1 row)

postgres=# select version();
                                        version                                        
---------------------------------------------------------------------------------------
 PostgreSQL 12.3 on x86_64-pc-linux-musl, compiled by gcc (Alpine 9.3.0) 9.3.0, 64-bit
(1 row)

postgres=# 

debian

Looks like the master version could easily support this since the critical dependencies are being built from source.

yes .. if the debian base is important, then the current workaround:

• create a copy : https://github.com/postgis/docker-postgis/blob/master/12-master/Dockerfile
• replace the ENV variables ... with your preferred version
• and build the image on your local machine ..

The current geos version in the Dockerfile :

ENV GEOS_VERSION master
ENV GEOS_GIT_HASH 19dc3b19338c2aded5197ca0e5a5456b028defbd

and should replace with

ENV GEOS_VERSION 3.8.1
ENV GEOS_GIT_HASH 24650422b3982f17cc493fe92a70228f2ad624b4

based on this command:

git ls-remote --tags   https://github.com/libgeos/geos.git | grep 'refs/tags/3' | grep -Fv  -e 'alpha' -e 'beta' -e 'rc' | tail -n1
24650422b3982f17cc493fe92a70228f2ad624b4    refs/tags/3.8.1

[phillipross]

Finally having read back through this issue... i'm curious to what people believe are the proper semantics of "working" and "stable" with regards to releases of dependencies. As it stands now, for debian based images, this repo piggybacks off of debian packaging. If debian packages are not considered stable and working, it seems only fair to file issues against the actual debian packages rather than the container image builds. But I think this only applies to the debian packaging versions provided by this repo.

The alternatives layed out by @ImreSamu should be much more workable... but are they acceptable? I think this is the question that we'd like to answer. Otherwise I think this issue can be closed. Thanks!

[d3mon187]

I agree it would be helpful to have a middle ground between bleeding edge 12-master and the quite old debian aligned 12-3.0, and go with latest version tag according to each dependency author. Not sure if that would be more work, but it might make sense to change the docker "latest" to function as this build.

Here's an example of what it might look like currently: ENV SFCGAL_VERSION v1.3.8 ENV SFCGAL_GIT_HASH 7e91a52fd90ef47e2f0b8925145e59ef1043fdd4 ENV PROJ_VERSION 7.1.1 ENV PROJ_GIT_HASH 94cfdfec9d51f0befb5c8fc5184329a3d7331333 ENV GDAL_VERSION v3.1.3 ENV GDAL_GIT_HASH 1be35bb911e08985260e9721b884fc0ec90be386 ENV GEOS_VERSION 3.8.1 ENV GEOS_GIT_HASH 24650422b3982f17cc493fe92a70228f2ad624b4 ENV POSTGIS_VERSION 3.0.2 ENV POSTGIS_GIT_HASH 2fb2a18c26e069f7c2edb34d32ed8c5e5165932d

Then change "&& git reset --hard FETCH_HEAD \" on each dependency to

&& git fetch --tags \
&& git checkout ${dependency_VERSION} \

excuse my lack of git/docker knowledge if there is a better way. Thanks for the helpful Docker!