Re: [ft-devel] web page for the forthcoming 2.2.0 release

[Frederic Crozat]

Le lundi 23 janvier 2006 à 10:53 +0100, david turner a écrit :
> Hi Werner and all,
> 
> > Perhaps we shall *rename* the library to, say, `libft2', instead of
> > `libfreetype', together with a new API prefix `FT2_' instead of `FT_'.
> > This would avoid the whole mess.
> >
> >   
> Simply changing the library name is not going to change a lot of things 
> due to the way dynamic
> linking works with ELF, it's simply equivalent to changing the so 
> version number.
> 
> Now, if we talk about a new API prefix, we're essentially asking that 
> *all* clients that use FreeType
> be rewritten to use it, or they'll be stuck with 2.1.10 which we don't 
> want to maintain anymore.
> 
> However, the percentage of "rogue" clients (i.e. the one that are going 
> to break due to the new install) is,
> much smaller, and easier to spot if you have access to their sources 
> (since simple grepping is sufficient)
> 
> Another option is to use a new API prefix internally, but provide 
> backwards compatibility macros like:
> 
> #define  FT_New_Face     FT2_New_Face
> 
> so that clients can be recompiled without modifications. The macros 
> *should* be disabled when building
> the library, to that the corresponding object files only contain FT2_ 
> functions. This will avoid any bad
> ELF magic to happen (though it may make debugging fun :-)
> 
> However, this will *not* prevent programs from being linked to both 
> libfreetype.so.6 and, say, libft2.so.1 or
> wathever. Even though the probabilities of crashes will be reduced, it 
> might produce unexpected results.
> 
> And it will *still* break rogue clients that are compiled against the 
> new version. Which is why I'm wondering
> if it will solve anything at all ? Sure, you can use your package 
> manager to refuse to install libfreetype.so.6 and
> libfreetype.so.7 together, but you won't be able to install 
> libfreetype.so.7 until all rogue clients are patched
> anyway.
> 
> In other words, the big deal are the rogue clients, not all programs 
> that use FreeType. We need to spot these,
> and provide patches before making a public release.
> 
> Another option is to have ./configure refuse to install freetype 2.2.0 
> if a previous release of the library is
> detected on the system; that is, unless you use a super-duper parameter 
> like --please-destroy-my-desktop
> that only the cautious will care to use.
> 
> Any comments ?

Well, from a distro point of view, it is enough to jump bump freetype
major to 7 :
-it will allow old non built programs to be used with freetype 2.1.10
(or earlier), without breaking any compatibility
-you can completely remove private headers from 2.2.0 and since programs
will have to be rebuilt to use freetype 2.2.0, you know only programs
respecting the new cleaned API/ABI will be able to be compiled.

What should not be done is to keep the old soname (libfreetype.so.6)
which means, by contract, that the ABI wasn't changed while in fact, it
was changed and some older programs won't be able to run with the new
freetype.

-- 
Frederic Crozat <address@hidden>
Mandriva