Re: pending/recent geo package changes, especially proj

[Greg Troxel <gdt%lexort.com@localhost>]

Jim Spath <jspath55%gmail.com@localhost> writes:

> On Mon, May 20, 2024 at 9:28 PM Greg Troxel <gdt%lexort.com@localhost> wrote:
>
>> tl;dr: If you depend on proj with any software that isn't actively
>> maintained, please test wip/proj and let me know what you are using.
>
> (I don't think I do; how do I verify?)

Run `pkg_info proj`, see what depends on it, and for each, see if
they've had a release in the last year or two.  Check also that they
aren't saying that you need old proj because they refuse to update their
code, if you want, but I'm really not hearing about that any more.

I have the following installed and they all built ok with proj 8.  (gdal
3.5 which is in tree is ok too.)

  gdal-lib-3.9.0
  libgeotiff-1.7.2rc1
  libspatialite-5.1.0nb1
  osm2pgsql-1.3.0nb15
  postgresql12-postgis-3.4.2nb4
  qgis-3.34.6nb1
  vtk-9.2.6nb7

At this point I am not aware of anything that isn't ok, but since I'm
about to land an update which might break something odd that I don't
know about, with the attitude that if so that thing is not ok, I'm
running it up the flagpole to see.

>> qgis is now at 3.34, ...
>
> Great! The main feature missing I would like in the pkgsrc version is
> enabling get-tagged PDF export. Our gdal support is lacking this, from my
> view.

From mine as well.   If you had read pkgsrc/geography/gdal-lib/Makefile:

  # \todo: Support geopdf by including poppler, PoDoFo, or PDFium.
  # https://gdal.org/drivers/raster/pdf.html

you'd know that I agree but haven't gotten to understanding how the
consequences of that bloat trade off against utility, and which choice
is best :-) (I have also started down the path of producing geopdf
maps.)  However, I think our gdal can currently produce geopdf, but not
read them.  Still, it should do both.

You are of course welcome to locally modify your copy of pkgsrc and add
in a bl3 line for one of those and rebuild gdal.  With that approach,
you don't have to answer the question of what's best for the overall
pkgsrc community....

>> There's some chance qgis will end up tracking every release instead of
>> LTR; please let me know if you have an opinion ...
>
> I am running QGis on several platforms, where newer or older versions are
> supported. Windows has the newest, and I have installed 3.32 and 3.36. The
> Raspian OS on Pi's can produce geotagged PDFs, but is still stuck at "QGIS
> 3.10.14-A Coruña 'A Coruña' (exported)". For me, having more than one
> version would be a plus, though not required for the complexity of my
> mapping projects.

3.10 is wicked old.

Debian 12 has 3.22, which is now two LTRs ago.

AIAI, raspbian has been renamed to Raspberry Pi OS, and that also has
3.22, because it's remixed Debian 12.

If we were to have more than one, I think it would be

  LTR
  latest release

with the caveat that I'd consider a release actually released when the
.1 happens.  And, I would lean to "you can install one or the other",
not having both.  Overall, it seems like having multiple is more work
for not so much gain.

I am also leaning to "just update to the latest as soon as the .1 is
out", as I am not finding evidence that the non-LTR releases are
unstable.  pkgsrc does not have any aspect of LTS, so we don't need a
bugfix stream for a frozen version; we can simply move to the next
release.


You have made the point that trying to be compatible with people running
systems that lean to LTS is going to be too painful.  Partly that's
because it would have versions that, AFAICT, are no longer supported by
upstream, and partly because the list is going to be long.