Here's what I'd like to do with the tiff packages. I believe this will be relatively non-disruptive. Technically, I don't think I *have* to ask permission for this, but I want to do it as a courtesy to the release team, to give you the chance to suggest a different approach or influence the timing, and to make sure I'm picking the best approach. I hope you will find a few minutes to reply so I can move forward, and I hope I won't have to wait very long.
Current state: * The tiff source package in unstable is version 3.9.5-2. It includes binary packages libtiff4, libtiffxx0c2, libtiff4-dev, libtiff-tools, libtiff-opengl, and libtiff-doc. The libtiff4-dev package "Provides" and "Conflicts" libtiff-dev. * The tiff source package in experimental is version 4.0.0~beta7-2. It includes binary packages libtiff5, libtiffxx5, libtiff-dev, libtiff-tools, libtiff-opengl, and libtiff-doc. The libtiff-dev package "Provides" libtiff5-dev (reversing the sense from the older package where libtiff4-dev provided libtiff-dev) and both "Conflicts" and "Replaces" libtiff4-dev. This was to set the stage for an eventual tiff transition. * Some packages (not sure which ones) apparently embed tiff 4.x sources because they need BigTIFF support. This is bad from many angles. Proposed new state: * Upgrade the tiff package to 4.0.0-1 and upload to unstable. No other changes would be made to the package. * Create source package tiff3 in section oldlibs at initial version 3.9.5-3. Have it include libtiff4, libtiffxx0c2, and libtiff4-dev, and still have libtiff4-dev provide libtiff-dev for now. Drop libtiff-doc, libtiff-opengl, and libtiff-tools. (The libtiff-doc package from 4.x includes the older documentation as well.) Basically this would just be a copy of the existing package minus the duplicated packages. The libtiff4-dev package and tiff 3.x binary packages will stick around but move to the new source package. Their version numbers will continue in sequence, so upgrades will be seamless and automatic. Packages that build-depend on libtiff4-dev will be unaffected. Packages that depend on libtiff-dev alone (if any) will have to specify libtiff4-dev or libtiff5-dev explicitly. This is the only area that might cause a hiccup, but it should be minor. (Also, the tiff3 package would have to go through NEW, so there could be a very brief time when the libtiff4, libtiff4-dev, and libtiffxx02 packages might be uninstallable.) Packages that require tiff 4.x can explicitly depend on libtiff5-dev (or on libtiff-dev | libtiff5-dev). I believe this is a better alternative than just dropping the older packages entirely and forcing a full transition, but I would also be happy to do it that way if you want, though I think it will be much more difficult. Otherwise, I think we should wait until both versions are in the archive and then plan a more orderly transition that could culminate in the removal of the tiff3 source packages prior to the release of wheezy+1. As a reminder, there are ABI changes between libtiff4 and libtiff5, and there are very few source API changes, and they are clearly documented. The tiff libraries do not use versioned symbols, and there is no one right now how has time time and inclination to tackle this. It's basically not going to happen. Anyway, it's extremely unlikely that there will be any more ABI changes in the next many years. There are some packages out there that require features from tiff 4.x. We can help debian be the leader of getting the world to upgrade to the new version of the tiff packages. Thanks. -- 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/20120121113810.3089362963.qww314159@soup
