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 _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
