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

Greg Troxel gdt at lexort.com
Tue Sep 29 03:53:41 PDT 2020


rmrodriguez at carto.com writes:

> One thing I have pending is a PR to remove the dependency on
> libprotobuf-c by keeping it under our tree
> (https://github.com/postgis/postgis/pull/579). This way we remove
> issues with MVT not being available in some distributions, especially
> since I increased the minimum required version.

I don't think it's a good idea to include source code unconditionally.
I can see why you want to have it, for systems that have troubled
packaging systems.

Part of the point is that the norm in packaging systems is to view
included copies as a bug, because when fixes are made to a package, they
don't propagage to the N copies.  In the limit, and really far sooner
than that, this is unworkable.

It seems there could be an alternate approach:

  depend on libprotobuf-c normally and use it as Plan A

  include a copy which is normally not used

  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


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


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?
-------------- 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/b295b241/attachment.sig>


More information about the postgis-devel mailing list