Re: postgis - Mailing list pgsql-general

From Marc Millas
Subject Re: postgis
Date
Msg-id CADX_1aa-8_LD0KP31wYH8S8tNKJT50-WBHhR4GXCvXc2oeLAJg@mail.gmail.com
Whole thread Raw
In response to Re: postgis  (Imre Samu <pella.samu@gmail.com>)
List pgsql-general
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



On Wed, Jul 20, 2022 at 7:27 PM Imre Samu <pella.samu@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:
"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:
- 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.


pgsql-general by date:

Previous
From: Abdul Sayeed
Date:
Subject: Re: Patroni & PostgreSQL issue
Next
From: Aleš Zelený
Date:
Subject: Re: PostgreSQL 14.4 ERROR: out of memory issues