> 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. --Jay
