On Tue, Jun 28, 2005 at 10:53:45AM +0100, Will Newton wrote: > On Tuesday 28 June 2005 06:14, Steve Langasek wrote: > > On Mon, Jun 27, 2005 at 10:29:55PM -0500, Ming Hua wrote: > > > So from my understanding, it's urgent for libfreetype6 to bump its > > > shlibs from "libfreetype6 (>= 2.1.5-1)" to "libfreetype6 (>= 2.1.10-1)".
> > No. See bug #314385: this library package's *name* needs to change, > > because of the issue you describe below. > It looks like this is the case, I had hoped that the incompatibilities were > minor enough that it would be possible to add any missing APIs back in where > necessary. Ah; that's potentially an option as well -- it's your call as the maintainer, really, it's just that the current arrangement is buggy and needs to be fixed. :) > I had prepared an upload that fixed the s/Lookup_Size/LookupSize/ issue, but > I > was not aware of the Mozilla problems. > I think the best thing to do is add a freetype2.1.7 source package that > builds > libfreetype6 with an epoch and coordinate with upstream the change to the > soname - the next release looks like it is meant to break the ABI (more than > normal that is). > Does that sound reasonable? I'd rather not epoch the package but I don't see > any other choice here. Epoched libraries are more problematic than other epoched packages, because once packages start to be rebuilt against the newer version of the library, their dependencies are broken by the epoch. That allows for the ABI skew breakage to seep into testing, as opposed to being caught and fixed in unstable. Is there any chance of a quick transition to libfreetype7 or whatever, that doesn't require keeping a libfreetype6 around for backwards-compatibility (which would mostly just cause segfaults during the transition anyway)? -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
