Re: postgis

From: Imre Samu <pella(dot)samu(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: postgis
Date: 2022-07-20 17:26:38
Message-ID: CAJnEWwkenkFhpM=2JCCo4wqqG05bzhH14_SdGp=aT9vJmUt+vg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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:
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.
>
>
>

In response to

  • Re: postgis at 2022-07-20 16:31:08 from David G. Johnston

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2022-07-20 17:39:01 Re: Batch process
Previous Message David G. Johnston 2022-07-20 16:31:08 Re: postgis