tiff 4.x (libtiff5) transition
Congratulations on getting Wheezy out the door!
Wasting no time, I'd like to remind the release team that I'm really
hoping Jessie will ship with only one version of the tiff library:
version 4.x at whatever version is current at the time of the freeze for
Jessie. Getting everyone over to tiff 4.x will be a pretty involved
process that will require changes to a lot of packages. I've outlined
my suggested approach with the full understanding that the release team
may scrap it and come up with something completely different. Although
my time for debian is relatively limited, I am prepared to pitch in and
help get this done. The stage is already pretty much set for this
transition.
The vast majority of packages that use tiff 3.x will transition to tiff
4.x with no changes to their code. Those packages that already build
depend on libtiff-dev instead of libtiff4-dev may even get away with
just a binary NMU. There are some packages that may require small code
changes to take care of places where APIs have changed to support
bigtiff. (The reason for binary incompatibility is that some things
that used to be 32-bit are now 64-bit.) There may also be a small
handful of packages that will break because there were using non-public
APIs by doing stuff like copying internal tiff headers into their
sources, but at this point, I believe most of those issues have been
fixed by various upstreams, and a few changes have also been made to
tiff 4 in response to issues found in Rawhide as they look toward a
transition as well.
We have the following situation right now:
The 3.x version of tiff is no longer actively supported by upstream, and
tiff gets lots of security issues, so it would be in everyone's
advantage to get rid of it as quickly as we can.
tiff3 source package builds tiff 3.9.x and has soname "4", so its
runtime package is libtiff4. The current version in debian is 3.9.6,
but 3.9.7 was released during the freeze.
tiff source package builds tiff 4.0.x and has soname "5", so its runtime
package is libtiff5. The current version in debian is 4.0.2, but 4.0.3
was released during the freeze.
tiff3 source package:
builds libtiff4-dev, which provides libtiff-dev. These install
headers and libraries in the normal locations
tiff source package:
builds libtiff5-dev, installs headers and libraries in normal
locations, but it's very hard to use this package since libtiff5-dev
and libtiff4-dev can't both be installed at the same time. It's very
common with the tiff library to have it as both a direct and an
indirect dependency, which means you can only use libtiff5-dev if
nothing in either your forward or reverse dependency chain uses
libtiff4-dev.
builds libtiff5-alt-dev, designed to address the above problem. This
installs tiff 4.x headers and libraries in a non-standard location so
that it can be installed simultaneously with libtiff4-dev. It may
require the packager to take specific steps to get it, but tiff
supports pkg-config starting in 4.0.x, so if the packager uses
pkg-config, then nothing special is required. The libtiff5-alt-dev
package is needed by anyone who requires libtiff5, such as to provide
bigtiff support.
Both tiff3 and tiff source packages use versioned symbols. Several
packages in the archive already have both libtiff4 and libtiff5 in their
runtime dependencies. See also
http://release.debian.org/transitions/html/libtiff4-symbols.html
Here's my initial suggestion. This is probably going to be wrong since
I don't have as broad of a perspective as the release team, so feel free
to scrap it entirely and suggest something different. Bear in mind that
libtiff4-dev and libtiff5-dev can't be installed together, which is what
drives most of the complexity here. This is pretty disruptive in the
very short term, but I think it will converge to a stable state fast and
will facilitate a faster and more accurate transition. Again, feel free
to shoot it down, of course.
1. In the tiff3 source package: create libtiff4-alt-dev that installs
tiff 3.x headers and libraries in a non-standard location. Drop
libtiff4-dev and make sure nothing in the tiff3 package provides
libtiff-dev.
In the tiff source package: drop libtiff5-alt-dev. Rename
libtiff5-dev to libtiff-dev, and make sure nothing provides
libtiff5-dev.
Upload tiff3-3.9.7-1 and tiff-4.0.3-1 to unstable.
Notes:
This means neither libtiff4-dev nor libtiff5-dev will be valid.
Only libtiff-dev and libtiff4-alt-dev will be valid.
Rationale for not having libtiff-dev provide libtiff5-dev:
* Hardly anything can be depending on libtiff5-dev since it would
only be possible currently if you have no packages in your
dependency or reverse dependency chain that build depend on
libtiff4-dev.
* Not having a libtiff5-dev in the archive at all will make it
easier for us in dealing with some future hypothetical upgrade
to a newer non-binary-compatible version in the future. No such
upgrade is planned, and upstream is pretty much just in
maintenance mode, but you never know.
Rationale for not keeping libtiff4-dev:
* tiff 3.x does not support pkg-config. We can't install libtiff4
dev files in a standard path since they will then conflict with
libtiff-dev. Therefore, source packages that must have
libtiff4-dev will have to make changes to their builds anyway to
change include and library paths; simple binary NMU for this
case is not possible. Forcing them to change the build
dependency to libtiff4-alt-dev makes it easier to track which
packages need attention and which packages have already been
updated. Basically everyone with libtiff4-dev in their build
dependency list will either have to replace it with libtiff-dev
or replace it with libtiff4-alt-dev and update include and
library paths.
Right now, we have a stable state where the default is libtiff4,
most packages get libtiff4, those that need libtiff5 can get it
with special workarounds, and libtiff4 and libtiff5 can be
arbitrarily mixed in the dependency/build dependency chain.
This step can get us quickly to a new stable state that reverses
the roles of libtiff4 and libtiff5: the default becomes libtiff5,
most packages get libtiff5, those that need libtiff4 can get it
with special workarounds, and libtiff4 and libtiff5 can be
arbitrarily mixed in the dependency/build dependency chain.
Though things will admittedly be a little chaotic right after the
initial upload, we will quickly reach a point where new versions
can transition to jessie, and we can work "at our leisure" in
fixing the packages that need libtiff4-alt-dev.
2. Tell packagers (via mass bug filing?):
* If your package depends on libtiff-dev already, no action
required; the release team will automatically schedule binary
NMUs of your package.
* If your package depends on libtiff4-dev but can work fine with
tiff 4.x (most packages), replace your dependency on
libtiff4-dev with a new dependency on libtiff-dev.
* If your package depended on libtiff5-dev, change it to depend on
libtiff-dev, or to help future backporters, on libtiff-dev (>>
4.0.3-1~).
* If your package previously depended on libtiff5-alt-dev, change
it to depend on libtiff-dev (>> 4.0.3-1~) and remove any special
code in your packaging that you had to add to get
libtiff5-alt-dev. (If you were finding libtiff5 with
pkg-config, no action will be required.)
* If your package MUST continue to use tiff 3.x, then replace your
build dependency on libtiff4-dev or libtiff-dev with one on
libtiff4-alt-dev (which can coexist with libtiff-dev) and change
your build to look in /usr/include/libtiff4-alt for headers and
libraries in /usr/lib/<arch>/libtiff4-alt. (There is no
pkg-config support in tiff 3.x, unfortunately, so this will have
to be manual.)
3. Continue to monitor. Work toward fixing any issues that prevent
packages from dropping libtiff4-alt-dev.
4. Before jessie, when all issues are resolved, remove tiff3 source
package.
As I said, this is disruptive in the short term (basically between the
uploads of the new tiff packages and when people fix their build
dependencies), but I think it can converge quickly because none of the
steps required for developers (or NMU-ers) to follow are hard.
Basically no one has to change any source code or fix any bugs at this
point. The only thing they have to do is make sure -I and -L are
correct in their packages' builds, and this can likely be done pretty
easily for most packages.
I'm happy to discuss less disruptive ways to do this, but I worry about
having this drag on for ages, and I would also can't think of any less
disruptive way to do it that doesn't require most packages to be changed
twice instead of just once. But someone on the release team with more
experience in planning and managing transitions like this may come up
with something better that I have overlooked.
I'd obviously like to get on this as soon as possible, but I understand
that there are many competing priorities and will certainly work with
the release team to get this done at the appropriate time and in the
appropriate way.
--
Jay Berkenbilt <qjb@debian.org>
Reply to: