Re: proposed resolution to release-critical libtiff3g bugs
> 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
Reply to: