[gdal-dev] building against external tiff/geotiff sources ?

[Landry Breuil]

Hi,

currently some interesting features (for example jxl compression in
tiff) requires one to build against internal tiff/geotiff - after
looking at the code, from my understanding this is because the gtiff
driver reaches to internal tiff functions not present in the public API,
which (to me) is a valid reason.  Afaict the bundled copies dont diverge
from upstream, since even maintains both sides in parallel.

even if i know the internal/bundled copies of tiff/geotiff are regularly
updated to sync from upstream, that worries me a bit, because as a
packager i'm used to build against systemwide libraries for maintainance
reasons - eg security fixes land at one place in the systemwide
libraries and all consumers benefit from it. There's been some CVEs
fixed in libtiff, it hasnt had a maintainance release since then, and in
the OpenBSD portstree those fixes were backported to the port of 4.5.0
we have (eg
https://github.com/openbsd/ports/commit/96602ddb3eb21a87da2322c31794c49f2470ac40).

Thus, two questions:
- in the long run, are there plans to allow building against external
  libtiff/libgeotiff libraries/packages for all features 'restricted' to
the internal copies of those (eg stop relying on internal funcs, or put
those in the public API), or that'd be too much a maintainance hell ?

- would it be possible to allow building against external
  libtiff/libgeotiff _sources_ ? this way i'd still be able to apply
fixes to one place, but i also suppose that'll require a tight version
dependency on those..

what do other packagers of gdal think about it ? Providing an
option/flavor for end-users of the packaging system to build against
internal copies might also be possible, but that creates havoc in
dependency trees..

Thanks again for gdal, everyday i love using it to processes large
amounts of data in various ways, and i think we don't say enough how
awesome it is !

Landry