[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[tbm@cyrius.com: Re: proposed resolution to release-critical libtiff3g bugs]

At Martin Michlmayr's suggestion, I'm forwarding this information to
debian-release (to which I do not subscribe, by the way).  Attached
below is the text of a message I sent to bug 236247 and the submitters
of all the bugs that are merged with it.  Thanks for any comments you
have.  I hope this proposal is acceptable and that the current
libtiff3g (or the package updated as I propose) can make it into
sarge.

Thanks for your consideration.

-- 
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
--- Begin Message --- 
* Jay Berkenbilt <ejb@ql.org> [2004-07-17 15:59]:
> Executive summary: there are compelling arguments in favor of closing

Please forward this message to debian-release@lists to get their
approval, but it seems like the right thing to me.  As one of the bug
submitters, I can confirm that I cannot reproduce the bug with current
sid (i.e., it works for me now).
-- 
Martin Michlmayr
tbm@cyrius.com

--- End Message ---
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
<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.
Reply to: