2021.01.04 14:23 "[Tiff] Motions related to C99 use in libtiff", by Even Rouault

2021.01.10 16:50 "Re: [Tiff] Motions related to C99 use in libtiff", by Roger Leigh

So I see this vote as a 'in principle we should move in this direction' and do not believe it represents any kind of consensus about breaking depending apps.

I think there are ways to handle the migration which would address most of the concerns. I did a similar migration for Xerces-C++, so let me describe what we did there.

With Xerces-C++, we made the switch in a new minor release, enabling use of <cstdint> as part of adding C++11 support. Like this change, it was initially optional and would fall back to the older types if not present. We added the needed Autoconf and CMake logic (as here on the std-int-types branch), and then we assessed the downstream implications of the change by picking a few common distribution package managers, and rebuilding the world with the change in place to see the impact. We did this for both Debian and the FreeBSD ports which are the most comprehensive in terms of their size.

For each package which failed to build we:

This meant that in the short term there was a smooth upgrade for all the major distribution packages and their downstream derivatives, and that every piece of software using the library would eventually have a point release with the fixes in place for the longer term (at which point the distributions could drop their patches).

This requires us to put in the effort to do the investigation, patching and patch submission, but it looks like the number of packages is under ten. We can do the change and determine the exact number. It should be manageable.

Clearly this isn’t completely sufficient. Software which is not packaged would need to use the TIFF_LEGACY_TYPES macro to enable the compatibility macros in the short term, should they be currently using them, and eventually migrate to the standard types. But there is no driving need for the legacy types to be dropped; if they are opt-in and not enabled by default, they could be kept indefinitely so long as there was software which needed to build against older libtiff releases.

We could do a phased transition as I already detailed. However given the manpower we have and the timescales involved, I don’t see it providing huge value. With the compatibility macro, you can continue to compile existing code without trouble and that should be sufficient for most if not all projects. And if we do the above transition as I did for Xerces-C++, we can transition most of the extant public open source usage of libtiff en masse. It’ll take a few weeks to make, test and submit all the patches, and a bit longer for them all to be applied, but it’s quite achievable.

Regards,

Roger