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

[rmrodriguez at carto.com]

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

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

Yes and no. What I've personally seen as trending in the last few
years are applications that have minimal, if any, runtime
dependencies. I'm fairly certain most people, with the clear exception
of developers, would rather have Postgis libraries (.so/.dll/.dylibs)
with everything included and up to date (including GEOS, GDAL and
whatever extra), in a model similar to go or rust. It would certainly
make it easier to move to newer dependencies at will, but it has its
clear drawbacks (security and duplication for example). That being
said, I agree on the implicit thought that we should consider first
the people doing the things right (or healthy packaging).


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

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

Yeah. I think nobody expected MVT to have as much use as they are
having, so protobuf being optional made sense. Maybe it's time to make
it an error, so you either have 1.1 available or build using
--without-protobuf (then you get a big warning and the proper error
messages during runtime).

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

The code changes are in the .proto file, so it's not possible to ifdef
it, and keeping 2 different files would be a big pain (since those
generate different C APIs). I've also considered pushing the generated
c|h files, but if you generate them with 1.1.0+ then they will fail to
compile with releases previous to that because of a missing flag
(PROTOBUF_C_FIELD_FLAG_ONEOF), so we would be in the same situation.

At this point I'm inclined to drop the PR and enforce the existence of
libprotobuf-c 1.1+ unless explicitly disabled. I 100% don't want to
revert a performance improvement (especially around memory, which is
an issue with big MVTs) because of people running LTS distros.

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