Package: release.debian.org Usertags: transition This is basically the same as http://lists.debian.org/debian-release/2013/05/msg00127.html, and I know it is already on your list, but I thought it would be better to actually have a transition bug sitting in release.debian.org.
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. Also, I will probably upload 3.9.7 and 4.0.3 to unstable before the transition since it is not happening as soon as I wish it could, so the transition versions will probably be later. 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 <q...@debian.org> -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130726113303.1573243528.qww314...@jberkenbilt-linux.appiancorp.com
