Re: [ft-devel] Re: FreeType issues

[Steve Langasek]

On Fri, Jan 27, 2006 at 02:20:54PM -0500, Owen Taylor wrote:
> On Sun, 2006-01-22 at 03:57 -0800, Steve Langasek wrote:
> > Hi Werner,

> > On Sun, Jan 22, 2006 at 09:12:46AM +0100, Werner LEMBERG wrote:

> > > I've read your very interesting mail at

> > >   http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html

> > > What's your recommendation in the light of

> > >   http://freetype.org/freetype2/freetype-2.2.0.html

> > Thanks for writing!  I applaud the FreeType developers for making this
> > effort to clean up the exported interface of the library.  I know that
> > proper handling of library ABIs has been an evolutionary process for most of
> > us in the Free Software community, and by switching to -export-symbols,
> > you guys appear to be ahead of the curve.

> > At the same time, I'm dismayed that this page talks about how badly people's
> > desktops are going to break, and *not* about a library soname change; and
> > there's no indication that the -version-info "age" argument has been reset
> > in freetype2 cvs; even though the -export-symbols change is being made
> > *explicitly because you know people have been using private interfaces*.

> The issue that a soname changed as been mentioned elsewhere in this
> thread. If the FreeType soname is changed and you provide both
> libfreetype6 and libfreetype7 for Debian (as is the normal practice),
> then most of the 583 packages you've identified will be linking 
> against *both* libfreetype6 and libfreetype7 until they are rebuilt,
> because one of their dependent libraries (fontconfig, libgd, pango,
> whatever), links against the new freetype.

Yes, that is an issue.  We're working on getting as many of these
double-linkages fixed in Debian as possible, since it's not a sane
assumption that libraries will never undergo ABI changes; but that doesn't
directly benefit the rest of the world so long as Debian's libtool fixes
aren't integrated upstream.

One change that *would* mitigate the problems for other distributors (and
Debian) is, since freetype 2.2 will already include a linker script, to add
symbol versions to that linker script.  This would give, um... a 50-50
chance of avoiding segfaults (or other corruption) with both libfreetype6
and libfreetype7 loaded in memory, assuming that the package upgraded to the
libfreetype7 version is chosen randomly.  I don't know if you consider those
odds good enough to forgo a conflict between libfreetype6 and libfreetype7
in Red Hat; they seem good enough for me given that we would not want to
ship libfreetype6 at all in etch and therefore the problems would be wholly
limited to partial upgrades from sarge.

> If you made libfreetype7 conflict with libfreetype6, then the you
> wouldn't have that problem, and you'd just have a massive rebuild
> job. 

We'll have a massive rebuild job for etch either way, since we're already
caught on ABI changes with 2.1.10 in Debian unstable; it's just deferred
pending the release of freetype 2.2 upstream and a "final" ABI to rebuild
against.  If freetype 2.2 is released with the same libfreetype.so.6 soname,
we will still have to provide a transition for packages by renaming the
package itself to libfreetype6debian1 or the like, and still conflicting
with libfreetype6; so changing the soname can only make things slightly
better for us, it won't make it any worse.

> For this reason, it is less of an issue for distributions that
> don't provide compat packages ... a soname change just causes a big
> rebuild that is pointless for 98% of all packages and catches the
> 2% that have problems. (That 2% is pretty well known, however.)

> But beyond the world of nicely managed systems and distributions,
> there are a whole lot of systems with random libfreetypes floating
> around in one directory or another, which will also be subject
> to the two-versions problem.

That's indeed true, but AFAICT having random libfreetypes floating around is
pretty likely to cause problems for users *without* an soname change as
well, given the high profile of those libraries that are affected by the ABI
change.  I don't claim that changing the soname is a magic fix, but I do
think that the problems caused by an soname change are all bugs that need to
be confronted (in general), rather than just being accepted and worked
around.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
address@hidden                                   http://www.debian.org/

signature.asc
Description: Digital signature