Jay, I'm sorry for not replying to this earlier.
On Sun, Jul 18, 2004 at 10:33:43AM -0400, Jay Berkenbilt wrote: > 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! The solution you propose has significant negative consequences for both partial upgrades from woody, and for third-party software linked against libtiff. I don't see any extenuating circumstances here that demand that we settle for a partial fix. You are right that reverting the ABI change at this point would hurt more than it would help. I believe the appropriate solution here is to change the soname of libtiff.so.3 to something with a Debian-specific component (e.g., libtiff.so.3.debian), and to make a corresponding change to the name of the binary package (e.g., libtiff3g-debian). This will cause libtiff-using packages to be uninstallable in unstable while they transition, but it does allow us to contain the damage to unstable instead of propagating it into a stable release. Following this with a healthy dose of recompile NMUs should let us transition the whole lot in a couple of weeks, in time for sarge. Thanks, -- Steve Langasek postmodern programmer > ---------------------------------------------------------------------- > > As established in bug 236247 > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=236247> and > discussed upstream in the thread containing this summary > <http://www.asmail.be/msg0055065000.html>, 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 > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=236247> > > Discussion of the issue upstream > <http://www.asmail.be/msg0055065000.html> > > ---------- 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. >
signature.asc
Description: Digital signature
