[ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution

[david turner]

Hello everyone,

I'd like to re-activate the debate regarding how we're going to 
install/name the
next FreeType release in order to avoid some of the ugly problems discussed
previously.

As far as I have understood:

* Installing the next release as "libfreetype6.so" is going to break any 
rogue client.
 Even if we provide patches for the most important ones, correct 
installation remains
 probably problematic for a typical user. and we don't control what has 
been compiled/
 installed locally anyway.

* Installing the next release as "libfreetype7.so" is not going to solve 
the problem either,
 because:

 - some programs are going to be linked with both libfreetype6 and 
libfreetype7

 - due to the way ELF dynamic linking works, erratic code paths will be 
taken,
   resulting in incorrect behaviour or even crashes

 - some of this can be avoided if we avoid same-named functions in 
libfreetype6
   and libfreetype7 (e.g. using the "FT3_" prefix, instead of "FT_"),
   but there are still cases where a program obtains a FT_Face object
   through libfreetype7, then call an internal function in libfreetype6,
   later resulting in a crash.

I am a Linux user too, and believe that this behaviour is simply 
*unacceptable*.
We thus need a different way to solve this. Given that rogue clients do:

- call internal functions from libfreetype6 that were mistakenly exposed
  by our build system until now

- also peek/poke directly at internal fields of some FreeType objects


we must, and only can, ensure *binary* compatibility by the following:

 - first of all, install the next release as libfreetype6. RIGHT !!

 - provide the previous internal functions, or some *stubs*, in the
   new libfreetype6 library (but not from the installed headers !)

 - ensuring that the internal layout of FreeType objects in the new
   libfreetype6 is *compatible* with the ones in the old libfreetype6
   (at least recent releases, since these have changed already without
   too much problems).

Note that our goal is to prevent *crashes* from already installed 
applications
and libraries, *not* to ensure 100% correct behaviour. In other words, 
it is ok to
"cheat" by ignoring some request made through these "exposed" internal 
functions
(e.g. returning a not-implemented-error), or fill internal fields with bogus
values. it will depend on context and relative importance of each point.

And of course, the internal headers will _not_ be installed anymore, 
which means
that the source code of any rogue client shall be updated anyway.

to achieve this, we must:

- immediately freeze development on the current code base

- perform a massive diff between the content of "include/freetype/internal"
 between the 2.1.10 release and the current CVS, and study how we can stub
 each type, field and function defined here.

- do the required modifications, encapsulating each of the "old" internals
 in a configuration macro (e.g. FT_CONFIG_OPTION_OLD_INTERNALS)

- test, test, test, on existing installations. Preferabbly ones with old 
releases
 of fontconfig/libXft/Pango/Qt/etc...

- release something stable as early as possible.


Any comments ?

- David Turner
- The FreeType Project  (www.freetype.org)

***********************************************************************************
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the address@hidden and destroy the original 
message.
***********************************************************************************