Message-ID: <20040717155940.0251672159.qww314159@soup> Date: Sat, 17 Jul 2004 15:59:44 -0400 From: Jay Berkenbilt To: CC: , , , , , , , , , Subject: proposed resolution to release-critical libtiff3g bugs Executive summary: there are compelling arguments in favor of closing all these bugs and letting libtiff-3.6.1 go into sarge. The only change required to this package is an update to README.Debian. We have a bad situation now that's just going to get worse, so I hope my suggestion will be considered and implemented. It shouldn't take long to read through the rest of this message as I have made a strong effort to lay out the arguments in a clear fashion. I've also discussed this with upstream and have referenced that conversion in this message. Thanks for your consideration! ---------------------------------------------------------------------- As established in bug 236247 and discussed upstream in the thread containing this summary , all of these bugs have been traced back to an accidental application binary interface (ABI) change in libtiff3g. The change causes applications that use the TIFFRGBAImage structure to crash or otherwise not work properly when compiled with libtiff version 3.5.7 and run with version 3.6.1 or vice versa. Upstream acknowledges that this was a mistake. Version 3.6.1 is the last version of libtiff that will be released as libtiff.so.3. (To be complete: programs that only use the "TIFF" type, and not the "TIFFRGBAImage" type, will most likely continue to work properly with either version of the library. There are a few other minor changes, but they may or may not impact the public ABI.) I strongly believe that the right thing to do now is to let this into sid anyway. I will explain my reasoning here. I hope you will find my arguments compelling enough to accept my proposed solution so we can get libtiff3g-3.6.1 into sarge. Please note: I fully understand that forcing sid's libtiff.so.3 into sarge even though it is not fully compatible with the existing libtiff.so.3 in sarge is a Bad Thing. However, I am recommending this solution because I think it is better than all the other alternatives. The rest of this message explains why. These bugs have been left open for many months now -- long enough that the problems are mostly no longer reproducible in sid because the applications or supporting libraries have long since been rebuilt with the current version of libtif3g. Most notable among these would be gdk-pixbuf, which is part of the libgtk2.0 (gtk+2.0) package (and also libgdk-pixbuf2 for an older version). In fact, the situation has flipped around so that, in some cases, a program may work in sid but not in sarge. For example, gqview (which is the same in sid and sarge) now fails to view tiff files with version 3.5.7 of libtiff (in sarge) but is able to view them with version 3.6.1 (in sid). It is impossible at this point to change the fact that, for the last more than four months, libtiff.so.3 in sarge has been incompatible with libtiff.so.3 in sid. There are, logically, only two possible ways to fix this: 1. Replace the sid version with something compatible with the sarge version. (BAD) 2. Move the version in sid into sarge. (BETTER) Option 1 (replacing the version in sid with something compatible with the version in sarge) would have been the right solution if it had been done right away, before anything in sarge had been compiled with 3.6.1. Now, however, many applications and libraries in sarge, including gtk+2.0, were built against the version in sid and require that version to run properly. Therefore, if this option would be taken now, a very large number of applications and libraries in sarge (at least those in these bug reports) would no longer work. We would once again have to make sure that all these applications were rebuilt. Option 2 is unfortunate because it means we are knowingly breaking compatibility, but this is already a done deal at this point, but I believe it's justified. The underlying problem, an ABI change without an soname change, has been acknowledged by upstream. The next upstream version of libtiff will have different soname. (It will be at least 5.0.0 because FreeBSD has already worked around this problem on their own and is using 4.0.0 as the soname for libtiff 3.6.1.) Therefore, this is a one-time problem. This option will cause the least pain. Basically, pushing libtiff 3.6.1 into testing at this point seems like the lesser of 2 evils in terms of resolving this problem. When libtiff 3.7.0 or 4.0.0 or whatever it ends up being called comes out, a new source package will be created based on the soname of the shared library. People who maintain packages that currently rely on libtiff3g should update their packages to use the newer version. In other words, it will be handled in the same way that a new soname would always be handled. If my suggestion of just letting 3.6.1 go into sarge in its present form is followed, it is possible that some programs in sarge that use TIFFRGBAImage directly will break. This will happen to applications that were compiled with 3.5.7 and use this interface directly. There probably aren't very many of these because TIFFRGBAImage isn't the "primary" interface for accessing TIFF files, and many applications that can work with TIFF files do so indirectly by using another library that in turn uses libtiff. This is true with many of these programs, some of which use gdk-pixbuf. Programs or libraries that use libtiff but don't use this structure will most likely continue to work fine. In this case, those applications (or libraries) will need to be recompiled with version 3.6.1 to resolve the problem. This would be a simple matter of just recompiling the package: no changes to the source or dependencies would be required. On this basis, I recommend that the following text be included in README.Debian for libtiff3g: ---------- 8< ---------- As a result of an accidental upstream change to libtiff3g's application binary interface (ABI), some applications built with versions of libtiff3g earlier than 3.6.1 crash when run with this version of the library, and vice versa. If you have an application that suffers from this problem, please recompile your application with this version (3.6.1) of the library. For additional information on this problem, please see: Debian bug number 236247 Discussion of the issue upstream ---------- 8< ---------- A new libtiff that includes this text in README.Debian (possibly replacing the existing text which is pretty old and most likely no longer relevant) could be uploaded that closes all these bugs. As a side note, it's interesting and not necessarily surprising to observe that the "testing" mechanism doesn't in any protect against this type of problem. Although libtiff3g had release critical bugs and couldn't itself move into sarge, many applications or other libraries that use it were able to make it into sarge just fine because they didn't depend upon this specific version of libtiff. In other words, the "testing" mechanism believes, as it should, that the same soname means the same ABI. I've only been involved in Debian for a relatively short time, and I've already seen several discussions about this type of issue. To me, it says that package maintainers should act quickly and decisively when an accidental ABI change without corresponding soname change is identified. -- Jay Berkenbilt