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

[Greg Troxel]

rmrodriguez at carto.com writes:

> 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.

I can see why you don't want the conditional include, but I don't see it
as acceptable to break packaging norms and update security for the 95%+
of systems with healthy packaging.  (I note that even Ubuntu 16.04 is
not on the list of systems troubled by this.)

So the combination of:

  conditional is too much

  non-conditional is unreasonable

leads to

  don't do it.

> 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.

Well, Paul complained that we bumped the version when it seems that
maybe we don't really need to bump the version.  A fair complaint for
discussion, and thus we should ask:

  should we make the code cope with the old version and revert the
  dependency version bump

vs

  should we tell people intentionally running old code that building our
  new code on their old system is not our problem

In this case, we are talking about RHEL 7, which was released in 2014,
so I'd expect all packages in it to be at least 6.5 years old.

>>   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).

I think it's fine for postgis to just say we as an upstream don't
support this, and our dependencies are what they are.

> 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.

All true, but IMHO not reasonable to impose those desires as obligations
on open source project workers, or consequences of those desires on
people in the mainstream open source world.

As for sysadmin/user clashes, those are problems within other people's
organizations, and not our problem.  That issue is way bigger than
postgis.  And it's not ok to torque around people without this problem
because of organizations that make choices like this.

For people that want some LTS and some not, I think the only sane
approach is to have one prefix that is LTS and a different prefix that
has builds of modern code.  Or N prefixes like that. And postgis doesn't
have to do anything to accommodate that.

(Isn't there some kind of "flatpak" that is supposed to be a prefix with
everything bundled, for this very reason?  Isn't that then a reason that
it's really ok to ignore the LTS problem?)

>> 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).

Those reports are really about incorrect (or at least suboptimal)
packaging, and trying to help people essentially repackage.

If anything, the bug in postgis is to have dependencies be optional,
when they are both easy to provide and not burdensomem.  Skipping an
entire big feature due to skipping a huge dependency is one thing, but
having a small thing not work because of small thing, seems worse than
making people get and install the small thing.

So in summary:

  I think you and I agree about LTS/modern not being a supported or
  supportable concept.

  I object to the pull request (as being a negative on reasonable
  systems).

  I see depending on a library released in 2015 as entirely reasonable
  for postgis trunk and future releases in mid 2020.

  If it's possible to ifdef the code that needs 1.1 without really giving
  up much, so that it builds against 1.0, that seems reasonable.  But I
  think it's also reasonable to just say no.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20200929/e5e2b43d/attachment.sig>