> 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. > > >
