On Wed, Nov 17, 2004 at 01:10:01PM +0300, Yuri N. Sedunov wrote:
> On Среда 17 Ноябрь 2004 12:54, Dmitry V. Levin wrote:
> > On Wed, Nov 17, 2004 at 12:47:22PM +0300, Yuri N. Sedunov wrote:
> > [...]
> >
> > > > > P.S. Обновление glib2/libgtk+2 должно помочь в вашем случае. А вот
> > > > > стоит ли вешать баг и куда... Пусть подскажут разработчики, правильно
> > > > > понимающие "How to Write Shared Libraries".
> > > >
> > > > Возможные варианты ответа:
> > > > - на upstream glib2/libgtk+2, который меняет API как хочет
> > > > - на maintainer'а glib2/libgtk+2, который собирает и тестирует в Сизифе
> > > >   девелоперские версии библиотек
> > > > - на upstream gaim, который использует неправильный интерфейс
> > > > - ещё куда-нибудь
> > > >
> > > > Правильного ответа я не знаю, поскольку совершенно не знаком с
> > > > ситуацией.
> > >
> > > Учтя, что программы из M24 c glib2/libgtk+2 из M24 работают и программы
> > > из текущего Сизифа c glib2/libgtk+2 из текущего Сизифа работают, можно
> > > найти и свои собственные варианты ответов.
> >
> > Но ведь ничто (т.е. в данном случае зависимости пакетов) не препятствуют
> > частичному обновлению M24 пакетами из Сизифа с получением неработающих
> > программ, которые в полностью обновлённой системе работают.
> >
> > Так что ответ для меня не очевиден, думаю что и для большинства
> > пользователей тоже.
> 
> Ответ содержится в твоем высказывании.

В моём высказывании содержится уточнение вопроса, а не ответ.  Я не знаю,
кто виноват и с кого спросить в данном конкретном случае.  Если в
публичном API glib2/libgtk+2 произошли изменения без соответствующего
отражения в soname или versioning, то виноваты upstream glib2/libgtk+2 и ты.
В противном случае виноват gaim (upstream и/или maintainer).

Припоминаю жалобы на аналогичные проблемы при точечных обновлениях,
связанных с "нехорошими" обновлениями qt и некоторых других библиотек.


-- 
ldv