Hello libxft maintainers and release managers, I've been following the development of font related library packages in Debian, as some of the new features in the recent upstream releases are important for rendering CJK fonts. So I'm quite happy to see xft 2.1.8.2 entered unstable a few days ago.
However I also noticed that with the current library dependency handling, the API/ABI changes in the new libxft2 library (the new features I was looking at) could break testing soon. So I feel I should raise the alarm here. As I have the tendency of being overly verbose, let me show the problem first: On unstable with libfreetype6 2.1.10-1 and libxft2 2.1.8.2-1: $ objdump -T /usr/lib/libXft.so.2.1.2 | grep "FT_GlyphSlot" 00000000 DF *UND* 0000016b FT_GlyphSlot_Embolden $ objdump -T /usr/lib/libfreetype.so.6.3.8 | grep "FT_GlyphSlot" 00013d50 g DF .text 0000016b Base FT_GlyphSlot_Embolden 00013cf0 g DF .text 0000005d Base FT_GlyphSlot_Oblique On sarge with libfreetype6 2.1.7-2.4 and libxft2 2.1.7-1 (testing has the same versions): $ objdump -T /usr/lib/libXft.so.2.1.2 | grep "FT_GlyphSlot" $ objdump -T /usr/lib/libfreetype.so.6.3.5 | grep "FT_GlyphSlot" (no such symbols in both libraries) As everybody should already know, freetype's ABI has been changing wildly from release to release. In this case the related are two new public functions "FT_GlyphSlot_*" (not in private header, which means endorsed by upstream) added after freetype 2.1.7. From what I heard, xft 2.1.7 already had functions that use this API, but it's optional, and as libxft2 2.1.7-1 was compiled against libfreetype6 2.1.7 (or earlier), it didn't end up using it. Now unstable has the new libfreetype6 2.1.10 with such API, when the new xft 2.1.8.2 is built, it picked up the new API and start using it (it would also happen if we rebuild the same 2.1.7, as I understand). So far, no big deal. However besides all the problem libfreetype6 has (exporting symbols that was intended for private use only, then dropping and renaming these functions), it also doesn't handle the shlibs correctly. The currenly libfreetype6 package still has only >= 2.1.5-1, but it's ABI has changed a lot since 2.1.5-1 (I mentioned this in #316031). Now libfreetype6 2.1.10-1 is held out of testing for good reason, libxft2 can slip into testing because of this broken shlibs, but it uses symbols only available in libfreetype6 2.1.10-1. I don't know if any other packages are using this feature in libxft2, but I suppose there is, as the Chinese users are constantly discussing about the changes this new feature brings. I am even not sure it's as serious as I think it is, but I believe you are more knowledgable than I am to decide this, I just want to bring it to your attention. I also remember similar thing happend for cairo before. I'm cc:ing #314385 as that seems to be the "libfreetype6 is broken" blanket bug now. There probably should be a bug filed against libxft2, but as I said I am not quite sure what sure be done here, I'm not doing it yet. (An unrelated issue: it seems strange to me that both 2.1.7 and 2.1.8.2 version of xft build libxft.so.2.1.2. Shouldn't the version number of the shared library at least change a little bit?) Thanks for reading this long mail, and also for the great work you've been doing. Best wishes, Ming 2006.01.24 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]