Re: postgis - Mailing list pgsql-general
| From | Imre Samu |
|---|---|
| Subject | Re: postgis |
| Date | |
| Msg-id | CAJnEWwkenkFhpM=2JCCo4wqqG05bzhH14_SdGp=aT9vJmUt+vg@mail.gmail.com Whole thread Raw |
| In response to | Re: postgis ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Responses |
Re: postgis
|
| List | pgsql-general |
> 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:
"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.johnston@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.samu@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"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 contributorYes, 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.
pgsql-general by date: