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

[Greg Troxel]

rmrodriguez at carto.com writes:

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

Thanks for the clarification.

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

sounds good

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

I see.  Well, in that case, I think were we are is ok.
-------------- 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/36a1d201/attachment.sig>