Re: postgis

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(dot)samu(at)gmail(dot)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(dot)g(dot)johnston(at)gmail(dot)com> ezt írta (időpont: 2022.
> júl. 20., Sze, 18:31):
>
>> On Wed, Jul 20, 2022 at 9:21 AM Imre Samu <pella(dot)samu(at)gmail(dot)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.
>>
>>
>>