[postgis-devel] [postgis-users] PostGIS 3.1.0alpha2 is released

[rmrodriguez at carto.com]

On Tue, Sep 29, 2020 at 12:53 PM Greg Troxel <gdt at lexort.com> wrote:

>   if libprotobuf-c is not found or too old give a warning.  Better yet
>   fail with an error and an explanation that people can
>   --enable-internal-protobuf, which turns the error into a warning.
>
>   use the included copy
>

Yeahh, no. If we were to include it, it is because it ensures everyone
has the proper version, which also gives us the benefit of having a
uniform dependency. If we include it but only behind some obscure flag
we are going to be in the same situation again, since the people
complaining aren't usually the one building or packaging it, so
telling them to use a new flag is equivalent to telling them to update
their protobuf-c, and in that case I would rather do the later since
it doesn't require work for us (and keeps thing simpler). IMO either
we go all in and provide it and force its use (like wagyu, uthash or
ryu) or we keep the behaviour as it is, but having it under the tree
to not use it is a waste of resources. Keep in mind I only did this
because Paul complained
(https://lists.osgeo.org/pipermail/postgis-devel/2020-September/028609.html),
I have 1.3.3 in my OS.

>
> It also strikes me that this is a symptom of two things, one perhaps
> addressable, and one intractable:
>
>   A) Generally, packages should try not to require really recent versions
>   of things they depend on, because various systems have various
>   versions, even in reasonably healthy (non LTS) situations.

>
>   B) LTS systems are a major problem.  Or rather, the combination of
>   people choosing to run an LTS system and simultaneously wanting to run
>   new versions of some software, without building a whole separate tree
>   of dependencies, and expecting the new versions of software to build
>   against the ancient versions in their particular LTS.  Really, people
>   who choose LTS to get all that LTS goodness should be happy with
>   postgis as included in their LTS too (seriously).
>

I couldn't agree more with you, people expect to run the latest
Postgis with the latest functionality in their 4 year old LTS (with 8
year old packages). That being said, I think in part it is because
there is a difference between what sysadmins want and what final users
want, and not only that, some people want some LTS packages but not
others and that isn't always available.

>
> About protobuf-c, I just checked pkgsrc, and it has 1.3.2.  That's old;
> 1.3.3 was released in February.   However, the fact that nobody has
> updated it is a clue that no other software in pkgsrc requires 1.3.3.
>
> postgis seems to require 1.1.0.  That really seems ok!  So problem A
> does not exist in this case.  And 1.1.0 was released on January 2015.
> So I don't see that it's reasonable to expect current postgis to build
> against systems with code from 2015.
>
>
> Can you explain in more detail the situations in which requiring
> prtobuf-c released in 2015-01 is a problem?  Is this about accomodating
> problem B?

Yes. We used to require 1.0.5 for MVT and 1.1 for geobuf, but for
Postgis 3.1 the MVT dependency was raised to 1.1. IIRC, this was an
issue on some distributions (RH7 or Amazon Linux) but even before the
update there were quite a bit of reports because of an old/not
available library
(https://www.google.com/search?q=%22Missing+libprotobuf-c%22&oq=%22Missing+libprotobuf-c%22).



--
Raúl Marín Rodríguez
carto.com