right. so I scratch the debian vm, install a centos 7 and within minutes I have a postgres 12 with postgis 3.0.4 running. so easy.
regards. Marc MILLAS Senior Architect +33607850334 www.mokadb.com On Wed, Jul 20, 2022 at 7:27 PM Imre Samu <pella.s...@gmail.com> wrote: > > I would expect the 35 packages implied by the version policies of those > two projects. > > Based on my docker-postgis support - the "geos" is also important. > Now Bullseye(Debian11) geos version is 3.9 - and this is likely to > continue until the end of the cycle ( so no upgrade expected to 3.10,3.11) > > And the (next) Postgis 3.3.0 Release is not enabling all new features > with the current Bullseye - Geos version: > https://git.osgeo.org/gitea/postgis/postgis/raw/tag/3.3.0beta2/NEWS > > *"This version requires PostgreSQL 11 or higher, GEOS 3.6 or higher, and > Proj 5.2+.* > > *Additional features are enabled if you are running GEOS 3.9+ST_MakeValid > enhancements with 3.10+, * > *numerouse additional enhancements with GEOS 3.11+. * > *Requires SFCGAL 1.4.1+ for ST_AlphaShape and ST_OptimalAlphaShape.* > *"* > > And Postgis 3.2 also has some enhancements working only with geos 3.10+ ( > ST_MakeValid enhancements ) > And "Bookworm" Debian12 expected >= mid-2023. > so not easy ... > > Imre > > > David G. Johnston <david.g.johns...@gmail.com> ezt írta (időpont: 2022. > júl. 20., Sze, 18:31): > >> On Wed, Jul 20, 2022 at 9:21 AM Imre Samu <pella.s...@gmail.com> wrote: >> >>> > My general impression is that the packaging, at least for Debian, >>> > doesn’t actually understand how the PostGIS project handles versioning >>> support. >>> > But i may be missing something >>> >>> "PostGIS Pre-built Binary Distributions for various OS" >>> ---> https://trac.osgeo.org/postgis/wiki/UsersWikiPackages >>> >>> Debian is a conservative Linux. >>> >>> IMHO: >>> Packaging is not so easy, [ >>> https://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS ] >>> - there are [n.=7] Postgres version [9.6,10,11,12,13,14,15 ] [ now: >>> all supported in bullseye ] >>> - there are [g.=9 ] Geos version >>> [3.3,3.4,3.5,3.6,3.7,3.8,3.9,3.10,3.11] [ now: bullsey= 3.9.0 ] >>> - there are [p.=7 ] Proj version [ 4.8,4.9,5.x,6.x,7.x,8.x,9.x ] [ >>> now: bullseye = 7.2.1 ] >>> - there are [d.= 7 ] Gdal version [ 2.4,3.0,3.1,3.2,3.3,3.4,3.5] [ >>> now: bullseye = 3.2.2 ] >>> - there are [m.=5] Postgis version [2.4,2.5,3.0,3.1,3.2,3.3] [now: >>> bullseye= 3.2.1 ] >>> >>> And there are also projects based on PostGIS. >>> - Pgrouting [r.=7 ] [2.3,2.4,2.5,2.6,3.0,3.1,3.2,3.3] [ now: >>> bullseye= 3.3.0 ; postgresql-12-pgrouting ] >>> >>> So the ideal "end user" combination = n*g*p*d*m*r = 7*9*7*7*5*7 = >>> 108045 >>> >>> // disclaimer: I am a Postgis user and a >>> https://github.com/postgis/docker-postgis contributor >>> >>>> >>>> >> Yes, my expectation may be naive, but as the package name is >> "postgresql-[version]-postgis-[version]" I would expect the 35 packages >> implied by the version policies of those two projects. So that one can >> choose their combination and focus on patch releases within those two named >> projects. The OP seems to as well. Or maybe a functional subset so that >> some number less than 35 may exist but, say, you cannot combine v14 and 3.0 >> since 3.0 since 3.2 was the most recent release of PostGIS when PostgreSQL >> v14 came out. >> >> In any case it does sound like the request by the OP is not something the >> community has chosen to provide. Which means a choice on their part - move >> up PostGIS or compile from source. >> >> David J. >> >> >>
