<div dir="ltr">I've also been looking at this, because we were previously using internal TIFF and GeoTIFF but also other libraries with their own TIFF, plus another one that needed TIFF, so we presumably ended up with four linked versions!<div><br></div><div>I have reworked everything so that we use one external TiFF and GeoTIFF for everything, and it seems to work, but this thread now has me worried that we might be missing functionality.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 4, 2023 at 6:40 AM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sebastiaan Couwenberg <<a href="mailto:sebastic@xs4all.nl" target="_blank">sebastic@xs4all.nl</a>> writes:<br>
<br>
> On 3/4/23 11:10, Landry Breuil wrote:<br>
>> what do other packagers of gdal think about it ? Providing an<br>
>> option/flavor for end-users of the packaging system to build against<br>
>> internal copies might also be possible, but that creates havoc in<br>
>> dependency trees..<br>
><br>
> The Debian package will keep using the external tiff because we don't<br>
> want to deal with the tiff security updates in the embedded copy.<br>
><br>
> Features that are only available when using the embedded copy won't be<br>
> enabled in the Debian package.<br>
><br>
> The only sane way forward is to not use private functions of tiff.<br>
<br>
With s/Debian/pkgsrc/, +1.<br>
<br>
The right fix is that if gdal needs private APIs, to add public APIs in<br>
tiff.<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>