potential tiff transition, tiff 4.0.0 strategy
(Please CC me on replies; I am not subscribed to debian-release.)
After many moons, it appears that a final, non-beta release of libtiff
4.0.0 is imminent. tiff-4.0.0~beta7 is in experimental, and some 4.0
beta has been in experimental since August, 2009. I recently learned
that the tiff 4.0.0 sources are embedded in some existing packages,
which we know is really bad from a security perspective. While tiff 4
is almost entirely source-compatible with tiff 3, there are ABI changes,
and in some cases, a source-full upload may be required. For some
packages, especially those who are depending on libtiff-dev instead of
libtiff4-dev, it's possible that a binary NMU may be sufficient.
As you well know, the tiff library has a very long chain of reverse
dependencies, so managing a transition could be involved, but it
shouldn't really be all that complicated since there should be few
source changes. Many packages will have to change their build
dependencies. Also, most of the packages that are downstream from tiff
depend on it indirectly through other imaging libraries.
As I see it, we have two choices: supporting two versions of libtiff in
unstable at the same time for some period of time, or biting the bullet
and tackling the transition right off the bat. I don't have any window
into how ready the release team would be to swallow a tiff transition
right now. That said, having two versions of tiff in unstable at the
same time seems like it could cause more problems than it solves. Many
packages depend on libtiff indirectly, so it seems potentially easy for
a package to end up needing two versions at once, and libtiff does not
use versioned symbols. (And I don't have the bandwidth to tackle it,
and neither does upstream.)
My preference would be to just do a libtiff transition. With the
release of tiff 4.0.0, the debian version of tiff will be identical to
upstream since they are using "5" as the soname of the library in
response to our having moved to 4 as the result of an earlier accidental
ABI change. All our patches from 3.x are present in the upstream
version, and all security issues reported against the 3.x series have
also been fixed in 4.x. The 4.x libraries are already being used in
many projects and are already getting external security scrutiny, and
there is wide consensus that it is ready for prime time.
So, what is the recommendation of the release team? If you agree that
we should do a transition as soon as possible after the final 4.0.0 is
released (so that wheezy can have 4.x), do you have any guesses as to
when you would be ready for an upload?
--
Jay Berkenbilt <qjb@debian.org>
Reply to: