>>>>> In <[EMAIL PROTECTED]> 
>>>>>   Branden Robinson <[EMAIL PROTECTED]> wrote:

>> On Sat, Jun 07, 2003 at 11:20:01PM +0900, ISHIKAWA Mutsumi wrote:
>> > >> I got a report in private mail (grrr) from a person who ran into the
>> > >> very problem you describe, so I appreciate you tracking this down and
>> > >> fixing it.  Your analysis looks reasonable and I agree with your
>> > >> solution.
>> > 
>> >  Sorry, I found my mistakes by my self.
>> > 
>> >  1) PS_FontInfoRec was not changed between FreeeType 2.1.3 and
>> >     2.1.4. It makes after FreeType 2.1.4 release (please see
>> >     freetype-2.1.4/debian/patches/001-freetype-2.1.4+cvs20030601.diff).
>>
>> If this is true, then, FreeType maintainer: *please stop doing this*.
>>
>> Debian needs to have FreeType packages that are compatible with the rest
>> of the world's FreeType packages.
>>
>> Perhaps what we really need is a freetype-snapshot package, which ships
>> a libfreetype6-snapshot package which Conflicts/Replaces/Provides:
>> libfreetype6.  For reasons that should be obvious, there should be no
>> snapshot -dev package at all.
>>
>> Please, please, please, I beg of you, do not break binary compatibility
>> in library packages.

 Humm, I found a message from Werner LEMBERG posted to
[EMAIL PROTECTED] I believe libfreetype6 incompatible between
2.1.4-3 and 2.1.4-4.

  Application build with libfreetype6_2.1.4-4 (use PS_FontInfoRec)
will crash with libfreetype6_2.1.4-3.

  Application build with libfreetype6_2.1.4-3 (use PS_FontInfoRec)
will crash with libfreetype6_2.1.4-4.

 But SONAME is not changed yet (on upstream).


>>>>> In <[EMAIL PROTECTED]> 
>>>>>   Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>> >
>> >    You might want to reconsider the change...
>> > 
>> >         * src/type1/t1tokens.h: Change italic_angle, is_fixed_pitch,
>> >         underline_position, and underline_thickness to pointers.  Change
>> >         the type of the latter two to `fixed'.
>> > 
>> > in current freetype6 without a change in version numbering of the shared
>> > libraries.
>>
>> Our normal strategy is to increase the shared library version number
>> right before a new release (as suggested by libtool).  We will do
>> that, of course, but not now.
>>
>> Is there a better strategy?
>>
>>
>>     Werner

-- 
ISHIKAWA Mutsumi
 <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>

Reply via email to