jfm wrote: []
The original purpose is still stated in DescDetail as : "The freetype2 packages now exist only for compatibility with older Fink packages. Developers should use the freetype that is part of XFree86 for new packages."
This formulation comes from a time when there was no xfree86-4.0 and especially no xorg package yet. Right now we have no unique "freetype that is part of XFree86". We are forced to live with several different not really compatible freetype2 versions simultaneously, and this will remain so for a long time to come.
To recall the situation once more: We have
- version 2.1.0 in Apple's X11 (=xfree86-4.3.0). This is too old for quite a few packages, whereas others still work well with it. It is the standard for packages that do not choose a different freetype2 deliberately.
- version 2.1.3 in the current freetype2 package. This could be upgraded to 2.1.4 without any compatibility problem.
- version 2.1.4 in the current xfree86 package and possibly in Tiger's X11 (but the latter is unknown, of course.) Version 2.1.4 is still widely used.
- version 2.1.8 in the current xfree86(-4.4.99) and xorg sources and in the xorg package.
- versions 2.1.7 (jfm) and 2.1.9 (rangerrick and others) in experimental. 2.1.9 is the latest and required by a couple of future packages.
There are 3 groups with big API differences and binary incompatibilities: 2.1.0 | 2.1.3-2.1.6 | 2.1.7-2.1.9. Between 2.1.7 and 2.1.9 there are only differences in the bug population, but between 2.1.4 and 2.1.7 there are serious API differences, and it is not clear if the binary incompatibility can be patched over completely (I doubt it).
Besides the real functional differences, there are artificial incompatibilities, like the obnoxious error that recent freetype/freetype.h produces when it is #included under this name. In addition there are the library compatibility_versions: 6.3.0 for Apple X11 and Fink's xfree86, 6.3.5 for the xorg package, and by special libtool maths 10.0.0 for the Fink freetype2 packages of any version.
My personal option for a solution would be to
- first upgrade the current freetype2 package to 2.1.4. This is trivial to do. And to
- have an additional freetype219 package that installs everything (including all its library files) into %p/lib/freetype219.
This would allow new packages to choose between 2.1.4 and 2.1.9, every package would find at least one compatible freetype2 version, and there would be neither build time nor runtime conflicts. All freetype2-{dev,shlibs} and freetype219-{dev,shlibs} packages can be installed at the same time.
There remain unsolved problems which we will probably have to live with:
- Packages that don't care about freetype versions will get whatever is currently installed in /usr/X11R6, and they will build different debs for different X11s. Packages like qt3 should be encouraged to choose one of our versions.
- Often there will be two different freetype.6.dylibs loaded into memory at the same time, because X11's libfreetype will inevitably pop up in addition to ours.
-- Martin
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
