Re: RFC: define FontLibSharedFreeType=NO
>>>>> In <[🔎] 20030607181335.GY25454@deadbeast.net>
>>>>> Branden Robinson <branden@debian.org> 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
devel@freetype.org. 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 <20030608.055428.57256597.wl@gnu.org>
>>>>> Werner LEMBERG <wl@gnu.org> 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
<ishikawa@linux.or.jp>, <ishikawa@debian.org>, <ishikawa@netvillage.co.jp>
Reply to: