On Fri, Jul 23, 2004 at 11:53:02AM -0400, Jay Berkenbilt wrote: > > > On Fri, Jul 23, 2004 at 10:53:26AM -0400, Jay Berkenbilt wrote: > > [...] > > > The upstream libtiff maintainers are going to skip some soname > > > versions when they do their next release. This makes it possible for > > > distributions to resolve this on their own by releasing 3.6.1 as > > > libtiff.so.4. FreeBSD apparently did this. If we were going to > > > revert the ABI change, I think the only sensible way to do it would be > > > to revert libtiff3g back to 3.5.7 (with an epoch) and release libtiff4 > > > which would be 3.6.1. > > > > Hello, > > Yes, afaiui Steve suggested exactly this. (He just chose libtiff3.deb > > instead of libtiff4.) And then we rebuild everything against libtiff4 > > and make sure these rebuilt packages also make it to sarge and replace > > the broken packages there, which were built against libtiff3g with > > 3.6.1-ABI. > > cu andreas > Well, this would be the Right Thing to do, and it seems that there is > a good reason to do the Right Thing. > If we do this, forcing all these packages to recompile without any > changes would resolve the problem in sarge. The package maintainers, > at their option, could replace their dependencies on libtiff3g to > libtiff4 instead, or they could wait if they don't care about the > changes. > libtiff4 may include LZW support. Based on discussions on > debian-legal, the libtiff mailing list, and other places, along with > the fact that ppmtogif is now in main, it seems that this would be > safe at this point. This would provide added incentive for people to > rebuild with libtiff4. > The only thing then is that Steve said that he agreed that reverting > the ABI would hurt more than it would help and then proceeded to > suggest something that, to me, sounds like ABI reversion. I just want > to make sure that I'm not misunderstanding the suggestion. If the > consensus is that reverting the ABI is the right option, and I agree > that it is the cleanest solution, even if more painful, then I think > we should just proceed with that plan. I was proposing making the ABI change explicit. If you think libtiff3g is important enough to continue providing, then you can re-upload it after everything else has been recompiled; but the window for this is short, and I don't see the need. The important thing is that we not ship a libtiff3g that's incompatible with the one in woody. This can be done by shipping one that's compatible with woody, or it can be done by not shipping one at all. The latter is much easier to achieve; just replace libtiff3g with libtiff4, recompile everything currently linked against libtiff3g, and push this into sarge. Please note that, with the way the release plan is shaping up, you should plan to have all packages rebuilt by August 1 to allow time for fixing any new FTBFS bugs and for the delays in propagation into testing. Assuming no other changes are made to the packages, I would also suggest that a medium urgency upload is appropriate in these cases. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature