[postgis-devel] Proposal: drop support for libproj < 6.1 in PostGIS 3.3.0

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

>> Not ubuntu but as proj packager for pkgsrc, I got stuck at 6.3.2.  Not
>> for a good reason, but moving beyond that gets into dealing with the
>> proj CDN and a different format of proj data.  Part of the issue is that
>> proj people think it's reasonable to download on the fly and manage
>> permissions of who can put downloaded stuff where, and packaging people,
>> not so much.
> That's a rather oriented way of presenting things:
>
> - Networking mode is opt-in (at build time, and at runtime). You can
> still use good old files on your local disk.
>
> - You can use still old .gtx/.gsb grids of past proj-datumgrid packages.
>
> - The PROJ database has aliases for those old names and the new
> GeoTIFF files, at leat for all grids we knew before the transition to
> GeoTIFF files, and the aliasing work in both direction: if a user
> refers to a .gtx/.gsb grid and they have instead the corresponding
> geotiff file it will be used. So the transition should be smooth.
>
> - Building PROJ 7 and above shouldn't be a big deal if you already
> build GDAL as it has a subset of its dependencies (curl, geotiff,
> sqlite3).
>
> I can understand that the amount of grid data we have collected in
> recent years can be a problem from a packaging point of view, but
> that's a problem of "rich people" as one say. As a least effort, you
> can still provide the good old proj-datumgrid-1.8 package of 6.3 MB
> and things will still work as before, even if not fully optimal in
> terms of what is possible.

I didn't mean to say the new world was bad.  I was trying to say that it
raised a bunch of issues as to how to deal with it, and that I have
simply not gotten to dealing with them.  For example, there are a lot of
choices above, and in packaging I have to make decisions about which
choices to make, and which to expose to the users.  I would have to try
out how downloading works for multiple users, and where it caches them,
and if that all works as I expect (probably it does).  I have a huge
TODO list, and updating proj from 6.3.2 to 8 simply hasn't bubbled to
the top compared to my estimate (perhaps incorrect) of how long it's
going to take.

I agree with your point about "rich people's problem" with the much
larger grid data, but it's still a more complicated world within which I
have to make choices on behalf of users.  The previous "just include all
the grids in the proj package" approach was 1.5G; that was an iffy
choice (many would say bad choice) then, and it no longer seems
semi-reasonable.

Plus, I don't know how many of the packages that depend on proj are
going to be left behind, as I think (no need to explain, I will look it
up and try it myself) that going beyond 6.3 has API withdrawals.  With
every API withdrawal I have to trade off "benefits of new to users" and
"removing packages that no longer build".

My real point was similar to how medicine considers all-cause mortality
as the metric of interest when evaluating treatments.  I'm not trying to
blame proj, or anything else for the lack of update in pkgsrc.  I am
simply pointing out that it *has not happened*, and that this is perhaps
a clue that it is difficult.  It might instead be a clue that I have
been too busy, but we seem to have another data point.

And therefore, I suggest that postgis requiring >= 6.3.x seems entirely
reasonable, as I have no data points that systems (that do updates, vs
LTS) have any good reason to be before 6.3.  But requiring >= 7 feels
aggressive.

It won't bother be personally, because if it becomes a problem for me
that proj is at 6.3.2 in pkgsrc, I'll get around to updating.  That's
going to happen at some point, and every quarter for about a year now
I've been telling myself to do it.
-------------- 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/20220212/e5fe53f1/attachment.sig>