2008.12.21 15:35 "Re: [Tiff] 3.9.0 release, Was: tiffvers.h - TIFFLIB_RELEASE macro addition", by Jay Berkenbilt

I *do* feel like those who had some complaint against releasing 3.9.0 immediately need to step forward with appropriate code changes.

You make a good point, and I should have come forward earlier. I made the complaints, and I will offer the appropriate code changes.

Certainly they should be afforded time to develop those patches, but my impression is that those patches aren't coming ever. So they either need to do so, or we need to move on without those changes.

Hopefully the citations I'll make here will help.

The exact change is the addition of these two fields:

        uint16 SubsamplingHor;                  /* subsampling factors */
        uint16 SubsamplingVer;

into _TIFFRGBAImage as defined in tiffio.h.

I believe an attempt was made to fix this in version 1.79, but that fix was checked into the trunk rather than into the 3.9 branch. I am now going through the code to figure out exactly what was fixed. I will backport the changes to the 3.9 branch and post through the bug tracking system. I'll then post the details to the list.

I'm not aware of the specific change that was made, so I can't guarantee that my patch won't break anything, but I'll at least do my usual testing that I do as debian maintainer.

Speaking as the debian tiff maintainer and the person who pointed out the specific problem with 3.9.0 breaking ABI compatibility, I should point to the original posts. First, I posted details about the exact nature of the breakage. Andrey asked Joris, who had made the change, to repair it. He partially repaired it but left a little bit of ABI breakage. Also, his fix was made on the trunk, not on the 3.9 branch. I probably should have been more forthcoming with fixes at the times of these earlier posts, but like everyone else here, I got distracted by other activities. Either way, I'm very appreciative of the fact that the libtiff maintainers take these issues seriously.

Here are some relevant posts:

Original thread starts here:

 - http://www.asmail.be/msg0054605258.html

Later discussion can be found here:

 - http://www.asmail.be/msg0055468514.html

It's just my opinion, of course, that some release is better than no release.

The situation is that conservative OS distributions like Debian won't pick up a new libtiff for about ten years if it is not ABI compatible with what they are already using. This is a problem for 3.9.X since it is supposed to be our avenue to get out critical fixes for older distributions well into the future.

Of course the same objection applies to libtiff 4.0 but libtiff 4.0 offers important new features so such objections may be ignored. In fact, since ABI compatibility is impossible, Debian maintainers are likely to find a way to offer it to their users without upsetting their applecart.

To be clear, the issue is not that debian won't pick up a version of libtiff with an ABI change. Debian takes ABI changes all the time. The issue is that if you change the ABI, you must also change the shared library soname. There are no objections about ABI changes in 4.0.0 because there is a new soname.

If you change the ABI and don't change the shared library soname, it is a bug. This is because existing applications that compiled against the old ABI will attempt to run with the new shared library, and they will fail. As evidence, recall the accidental ABI change introduced in version 3.6.1. This broke dozens of applications in debian and forced us to update the soname from 3 to 4, making debian inconsistent with upstream in this regard. Other distributions including certainly cygwin, and I think also FreeBSD and MacOS, though I'm not sure about those two, also deviated from upstream. The libtiff developers are aware of this and, to bring everyone back in sync, have set the soname version to 5 for version 4.0.0.

I hope that clarifies things.

I'll try to put a patch together this morning.

--Jay