[sisyphus] gaim в свете последних перемен

[sisyphus] gaim в свете последних перемен

[Ildar Mulyukov]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

       Здраствуйте,
ставится на "ура", а работает .. практически не работает.
altlinux-release-Sisyphus-alt20041013
libgtk+2-2.4.9-alt1.2
glib2-2.4.6-alt1
XFree86-libs-4.3.0-alt16
gaim-1.0.2-alt2

Толи зависимости нужны, толи не знаю что. Короче, ИМХО, надо "свежак" 
проверять на последнем стабильном дистре. Видимо.
Спасибо за внимание.
Если нужно, могу на бугзиллу повесить.

БР, Ильдар

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================


[-- Attachment #2: gaim.bug.bz2 --]
[-- Type: application/x-bzip, Size: 9063 bytes --]

[sisyphus] Re: gaim в свете последних перемен

[Michael Shigorin]

On Tue, Nov 16, 2004 at 03:10:21PM +0300, Ildar Mulyukov wrote:
> gaim-1.0.2-alt2 Если нужно, могу на бугзиллу повесить.

Дырки-то в ём заткнуты?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: gaim в свете последних перемен

[Andrei Bulava]

Michael Shigorin пишет:
> On Tue, Nov 16, 2004 at 03:10:21PM +0300, Ildar Mulyukov wrote:
> 
>>gaim-1.0.2-alt2 Если нужно, могу на бугзиллу повесить.
> 
> 
> Дырки-то в ём заткнуты?

Нет, насколько мне известно из security-announce@ :-(

Голосуйте за https://bugzilla.altlinux.org/show_bug.cgi?id=5374 ;-)

vk@ в курсе, я его терроризирую всеми доступными способами (bugzilla, 
почта, теперь ещё и jabber) - буквально вчера об этом говорили. Если у 
vk@ не будет складываться, я постараюсь с ним договориться о создании 
gaim@packages.altlinux.org

-- 
// AB1002-UANIC

[sisyphus] Re: gaim в свете последних перемен

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Tue, Nov 16, 2004 at 06:00:18PM +0200, Andrei Bulava wrote:
> vk@ в курсе, я его терроризирую всеми доступными способами
> (bugzilla, почта, теперь ещё и jabber) - буквально вчера об
> этом говорили. Если у vk@ не будет складываться, я постараюсь с
> ним договориться о создании gaim@packages.altlinux.org

Дык договаривайся, чего думать-то.  Помогать -- не передавать :-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] gaim в свете последних перемен

[Andrei Bulava]

Ildar Mulyukov пишет:
>       Здраствуйте,
> ставится на "ура", а работает .. практически не работает.
> altlinux-release-Sisyphus-alt20041013
> libgtk+2-2.4.9-alt1.2
> glib2-2.4.6-alt1
> XFree86-libs-4.3.0-alt16
> gaim-1.0.2-alt2
> 
> Толи зависимости нужны, толи не знаю что. Короче, ИМХО, надо "свежак" 
> проверять на последнем стабильном дистре. Видимо.
> Спасибо за внимание.
> Если нужно, могу на бугзиллу повесить.

Пожалуйста, конкретнее. Пока могу только возразить, что "у меня всё 
работает" (c). А именно - регулярно использую yahoo, icq, jabber.

P.S. altlinux-release-Sisyphus-alt20041102 + обновления всех пакетов, 
актуальных на 11 ноября, за исключением xorg-x11-*, который актуален на 
5 ноября, т.е. xorg-x11-*-6.8.1-alt12.

-- 
// AB1002-UANIC

Re: [sisyphus] gaim в свете последних перемен

[Vital Khilko]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Аўт, 2004-11-16 at 15:10 +0300, Ildar Mulyukov wrote: 
>        Здраствуйте,
> ставится на "ура", а работает .. практически не работает.
> altlinux-release-Sisyphus-alt20041013
> libgtk+2-2.4.9-alt1.2
> glib2-2.4.6-alt1
> XFree86-libs-4.3.0-alt16
> gaim-1.0.2-alt2
  ^^^^^^^^^^^^^^^
у нас 1.0.3, altlinux-release-Sisyphus-alt20041115
> Толи зависимости нужны, толи не знаю что. Короче, ИМХО, надо "свежак" 
> проверять на последнем стабильном дистре. Видимо.
это на каком? Мастер 2.2?
> Спасибо за внимание.
> Если нужно, могу на бугзиллу повесить.
повесьте, только не забудьте описать симптомы, ибо "практически не работает" мало чем может помочь.

[-- Attachment #2: Гэтая частка паведамленьня падпісана электроным подпісам --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] gaim в свете последних перемен

[Ildar Mulyukov]

Vital Khilko wrote:

>On Аўт, 2004-11-16 at 15:10 +0300, Ildar Mulyukov wrote: 
>  
>
>>       Здраствуйте,
>>ставится на "ура", а работает .. практически не работает.
>>altlinux-release-Sisyphus-alt20041013
>>libgtk+2-2.4.9-alt1.2
>>glib2-2.4.6-alt1
>>XFree86-libs-4.3.0-alt16
>>gaim-1.0.2-alt2
>>    
>>
>  ^^^^^^^^^^^^^^^
>у нас 1.0.3, altlinux-release-Sisyphus-alt20041115
>  
>
неправильно. В Сизифе - только 1.0.2. См.

>>Толи зависимости нужны, толи не знаю что. Короче, ИМХО, надо "свежак" 
>>проверять на последнем стабильном дистре. Видимо.
>>    
>>
>это на каком? Мастер 2.2?
>  
>
Видимо, на 2.4. С чего 2.2???

>>Спасибо за внимание.
>>Если нужно, могу на бугзиллу повесить.
>>    
>>
>повесьте, только не забудьте описать симптомы, ибо "практически не работает" мало чем может помочь.
>  
>
Можно было бы обратить внимание не вложение в письмо.
Повешу.

Кто-нибудь в курсе, бэкпортами кто-нибудь уже занимается? На 2.4? :-)
БР Ильдар.

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] gaim в свете последних перемен

[Ildar Mulyukov]

Ildar Mulyukov wrote:

> Vital Khilko wrote:
>
>> On Аўт, 2004-11-16 at 15:10 +0300, Ildar Mulyukov wrote:  
>>
>>>       Здраствуйте,
>>> ставится на "ура", а работает .. практически не работает.
>>> altlinux-release-Sisyphus-alt20041013
>>> libgtk+2-2.4.9-alt1.2
>>> glib2-2.4.6-alt1
>>> XFree86-libs-4.3.0-alt16
>>> gaim-1.0.2-alt2   
>>
>>  ^^^^^^^^^^^^^^^
>> у нас 1.0.3, altlinux-release-Sisyphus-alt20041115 
>
> неправильно. В Сизифе - только 1.0.2. См.

то есть, прошу прощения, только вчера был 1.0.2

> <skip/>



-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] gaim в свете последних перемен

[Andrei Bulava]

Ildar Mulyukov пишет:
> Ildar Mulyukov wrote:
> 
>> Vital Khilko wrote:
>> неправильно. В Сизифе - только 1.0.2. См.
>  
> то есть, прошу прощения, только вчера был 1.0.2

Прошу прощения, что не разглядел аттач в письме, породившем нить обсуждения.

Я боюсь, что gaim-1.0.3 не изменит вашей ситуации.

$ rpm -qv glib2
glib2-2.5.5-alt1
$ rpm -qv libgtk+2
libgtk+2-2.5.4-alt1

Собственно, практика "точечного" обновления Сизифа может привести к 
таким последствиям. Честно говоря, я не знаю, сколько пядей во лбу 
должно быть у мантейнера gaim, чтоб отслеживать двоичную несовместимость 
всех возможных сочетаний версий glib2/libgtk+2

Возможно, я и ошибаюсь в своих выводах насчёт двоичной несовместимости, 
но такое _моё_ понимание http://people.redhat.com/drepper/dsohowto.pdf

P.S. Обновление glib2/libgtk+2 должно помочь в вашем случае. А вот стоит 
ли вешать баг и куда... Пусть подскажут разработчики, правильно 
понимающие "How to Write Shared Libraries".

-- 
// AB1002-UANIC

Re: [sisyphus] glib2/libgtk+2 API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

Hi,

On Wed, Nov 17, 2004 at 10:42:26AM +0200, Andrei Bulava wrote:
[...]
> Собственно, практика "точечного" обновления Сизифа может привести к 
> таким последствиям. Честно говоря, я не знаю, сколько пядей во лбу 
> должно быть у мантейнера gaim, чтоб отслеживать двоичную несовместимость 
> всех возможных сочетаний версий glib2/libgtk+2
> 
> Возможно, я и ошибаюсь в своих выводах насчёт двоичной несовместимости, 
> но такое _моё_ понимание http://people.redhat.com/drepper/dsohowto.pdf
> 
> P.S. Обновление glib2/libgtk+2 должно помочь в вашем случае. А вот стоит 
> ли вешать баг и куда... Пусть подскажут разработчики, правильно 
> понимающие "How to Write Shared Libraries".

Возможные варианты ответа:
- на upstream glib2/libgtk+2, который меняет API как хочет
- на maintainer'а glib2/libgtk+2, который собирает и тестирует в Сизифе
  девелоперские версии библиотек
- на upstream gaim, который использует неправильный интерфейс
- ещё куда-нибудь

Правильного ответа я не знаю, поскольку совершенно не знаком с ситуацией.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Yuri N. Sedunov]

On Среда 17 Ноябрь 2004 12:30, Dmitry V. Levin wrote:
> Hi,
>
> On Wed, Nov 17, 2004 at 10:42:26AM +0200, Andrei Bulava wrote:
> [...]
>
> > Собственно, практика "точечного" обновления Сизифа может привести к
> > таким последствиям. Честно говоря, я не знаю, сколько пядей во лбу
> > должно быть у мантейнера gaim, чтоб отслеживать двоичную несовместимость
> > всех возможных сочетаний версий glib2/libgtk+2
> >
> > Возможно, я и ошибаюсь в своих выводах насчёт двоичной несовместимости,
> > но такое _моё_ понимание http://people.redhat.com/drepper/dsohowto.pdf
> >
> > 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 из текущего Сизифа работают, можно найти и 
свои собственные варианты ответов.

-- 
Yuri N. Sedunov
11/17/04 12:40:07

Re: [sisyphus] glib2/libgtk+2 API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

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 пакетами из Сизифа с получением неработающих
программ, которые в полностью обновлённой системе работают.

Так что ответ для меня не очевиден, думаю что и для большинства
пользователей тоже.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Yuri N. Sedunov]

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 пакетами из Сизифа с получением неработающих
> программ, которые в полностью обновлённой системе работают.
>
> Так что ответ для меня не очевиден, думаю что и для большинства
> пользователей тоже.

Ответ содержится в твоем высказывании.

-- 
Yuri N. Sedunov
11/17/04 13:03:54

Re: [sisyphus] glib2/libgtk+2 API changes

[Ildar Mulyukov]

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 пакетами из Сизифа с получением неработающих
>>программ, которые в полностью обновлённой системе работают.
>>
>>Так что ответ для меня не очевиден, думаю что и для большинства
>>пользователей тоже.
>>    
>>
>Ответ содержится в твоем высказывании.
>
Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] glib2/libgtk+2 API changes

[Yuri N. Sedunov]

On Среда 17 Ноябрь 2004 13:16, Ildar Mulyukov wrote:
> 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 пакетами из Сизифа с получением неработающих
> >>программ, которые в полностью обновлённой системе работают.
> >>
> >>Так что ответ для меня не очевиден, думаю что и для большинства
> >>пользователей тоже.
> >
> >Ответ содержится в твоем высказывании.
>
> Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?

"в данном случае зависимости пакетов"  должны препятствовать "частичному 
обновлению M24 пакетами из Сизифа с получением неработающих
программ, которые в полностью обновлённой системе работают"

-- 
Yuri N. Sedunov
11/17/04 13:15:15

Re: [sisyphus] glib2/libgtk+2 API changes

[Ildar Mulyukov]

Yuri N. Sedunov wrote:

>On Среда 17 Ноябрь 2004 13:16, Ildar Mulyukov wrote:
>  
>
>>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 пакетами из Сизифа с получением неработающих
>>>>программ, которые в полностью обновлённой системе работают.
>>>>
>>>>Так что ответ для меня не очевиден, думаю что и для большинства
>>>>пользователей тоже.
>>>>        
>>>>
>>>Ответ содержится в твоем высказывании.
>>>      
>>>
>>Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?
>>    
>>
>
>"в данном случае зависимости пакетов"  должны препятствовать "частичному 
>обновлению M24 пакетами из Сизифа с получением неработающих
>программ, которые в полностью обновлённой системе работают"
>
То есть багу надо вешать на gaim и ещё сотню программ, чтобы все 
мэйнтейнеры прописали Require?

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] glib2/libgtk+2 API changes

[Yuri N. Sedunov]

On Среда 17 Ноябрь 2004 13:22, Ildar Mulyukov wrote:
> Yuri N. Sedunov wrote:
> >On Среда 17 Ноябрь 2004 13:16, Ildar Mulyukov wrote:
> >>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 пакетами из Сизифа с получением
> >>>> неработающих программ, которые в полностью обновлённой системе
> >>>> работают.
> >>>>
> >>>>Так что ответ для меня не очевиден, думаю что и для большинства
> >>>>пользователей тоже.
> >>>
> >>>Ответ содержится в твоем высказывании.
> >>
> >>Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?
> >
> >"в данном случае зависимости пакетов"  должны препятствовать "частичному
> >обновлению M24 пакетами из Сизифа с получением неработающих
> >программ, которые в полностью обновлённой системе работают"
>
> То есть багу надо вешать на gaim и ещё сотню программ, чтобы все
> мэйнтейнеры прописали Require?

Список из сотни программ, пожалуйста. Или хотя бы еще парочку, для которых 
потребуется прописать такие зависимости.

-- 
Yuri N. Sedunov
11/17/04 13:22:19

Re: [sisyphus] glib2/libgtk+2 API changes

[Ildar Mulyukov]

Yuri N. Sedunov wrote:

>On Среда 17 Ноябрь 2004 13:22, Ildar Mulyukov wrote:
>  
>
>>Yuri N. Sedunov wrote:
>>    
>>
>>>On Среда 17 Ноябрь 2004 13:16, Ildar Mulyukov wrote:
>>>      
>>>
>>>>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 пакетами из Сизифа с получением
>>>>>>неработающих программ, которые в полностью обновлённой системе
>>>>>>работают.
>>>>>>
>>>>>>Так что ответ для меня не очевиден, думаю что и для большинства
>>>>>>пользователей тоже.
>>>>>>            
>>>>>>
>>>>>Ответ содержится в твоем высказывании.
>>>>>          
>>>>>
>>>>Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?
>>>>        
>>>>
>>>"в данном случае зависимости пакетов"  должны препятствовать "частичному
>>>обновлению M24 пакетами из Сизифа с получением неработающих
>>>программ, которые в полностью обновлённой системе работают"
>>>      
>>>
>>То есть багу надо вешать на gaim и ещё сотню программ, чтобы все
>>мэйнтейнеры прописали Require?
>>    
>>
>Список из сотни программ, пожалуйста. Или хотя бы еще парочку, для которых 
>потребуется прописать такие зависимости.
>
Хорошо, хорошо. Я погорячился. Но такие программы появятся при следующей 
же пересборке [этих программ], насколько я понимаю.

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] glib2/libgtk+2 API changes

[Yuri N. Sedunov]

On Среда 17 Ноябрь 2004 13:28, Ildar Mulyukov wrote:
> Yuri N. Sedunov wrote:
> >On Среда 17 Ноябрь 2004 13:22, Ildar Mulyukov wrote:
> >>Yuri N. Sedunov wrote:
> >>>On Среда 17 Ноябрь 2004 13:16, Ildar Mulyukov wrote:
> >>>>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 пакетами из Сизифа с
> >>>>>> получением неработающих программ, которые в полностью обновлённой
> >>>>>> системе работают.
> >>>>>>
> >>>>>>Так что ответ для меня не очевиден, думаю что и для большинства
> >>>>>>пользователей тоже.
> >>>>>
> >>>>>Ответ содержится в твоем высказывании.
> >>>>
> >>>>Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?
> >>>
> >>>"в данном случае зависимости пакетов"  должны препятствовать "частичному
> >>>обновлению M24 пакетами из Сизифа с получением неработающих
> >>>программ, которые в полностью обновлённой системе работают"
> >>
> >>То есть багу надо вешать на gaim и ещё сотню программ, чтобы все
> >>мэйнтейнеры прописали Require?
> >
> >Список из сотни программ, пожалуйста. Или хотя бы еще парочку, для которых
> >потребуется прописать такие зависимости.
>
> Хорошо, хорошо. Я погорячился. Но такие программы появятся при следующей
> же пересборке [этих программ], насколько я понимаю.

Если таковые программы вдруг появяться, специально для Вас есть 
bugzilla.altlinux.org.

-- 
Yuri N. Sedunov
11/17/04 13:28:31

Re: [sisyphus] glib2/libgtk+2 API changes

[Ildar Mulyukov]

Yuri N. Sedunov wrote:

>On Среда 17 Ноябрь 2004 13:28, Ildar Mulyukov wrote:
>  
>
>>Yuri N. Sedunov wrote:
>>    
>>
>>>On Среда 17 Ноябрь 2004 13:22, Ildar Mulyukov wrote:
>>>      
>>>
>>>>Yuri N. Sedunov wrote:
>>>>        
>>>>
>>>>>On Среда 17 Ноябрь 2004 13:16, Ildar Mulyukov wrote:
>>>>>          
>>>>>
>>>>>>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 пакетами из Сизифа с
>>>>>>>>получением неработающих программ, которые в полностью обновлённой
>>>>>>>>системе работают.
>>>>>>>>
>>>>>>>>Так что ответ для меня не очевиден, думаю что и для большинства
>>>>>>>>пользователей тоже.
>>>>>>>>                
>>>>>>>>
>>>>>>>Ответ содержится в твоем высказывании.
>>>>>>>              
>>>>>>>
>>>>>>Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?
>>>>>>            
>>>>>>
>>>>>"в данном случае зависимости пакетов"  должны препятствовать "частичному
>>>>>обновлению M24 пакетами из Сизифа с получением неработающих
>>>>>программ, которые в полностью обновлённой системе работают"
>>>>>          
>>>>>
>>>>То есть багу надо вешать на gaim и ещё сотню программ, чтобы все
>>>>мэйнтейнеры прописали Require?
>>>>        
>>>>
>>>Список из сотни программ, пожалуйста. Или хотя бы еще парочку, для которых
>>>потребуется прописать такие зависимости.
>>>      
>>>
>>Хорошо, хорошо. Я погорячился. Но такие программы появятся при следующей
>>же пересборке [этих программ], насколько я понимаю.
>>    
>>
>Если таковые программы вдруг появяться, специально для Вас есть bugzilla.altlinux.org.
>
Я понимаю, что поступаю неправильно и даже неэтично по отношению к 
сообществу ALTLinux, но так получилось, что я не могу сейчас тратить 
время на переход XFree86->x.org, а без этого дистапгрейд невозможен. 
Извините.

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] glib2/libgtk+2 API changes

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

* Ildar Mulyukov <ildar@> [041117 16:36]:
> Я понимаю, что поступаю неправильно и даже неэтично по отношению к 
> сообществу ALTLinux,
Попробуйте хотя бы квотить по человечески.

-- 
Regards, Sir Raorn.
-------------------
Лично я использую ext2/ext3, поэтому с пакетом e2fsprogs у нас всё в
порядке, а всё остальное меня интересует в той же мере, что и "есть ли
жизнь на Марсе?".
		-- ldv in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Ildar Mulyukov]

Alexey I. Froloff wrote:

>* Ildar Mulyukov <ildar@> [041117 16:36]:
>  
>
>>Я понимаю, что поступаю неправильно и даже неэтично по отношению к 
>>сообществу ALTLinux,
>>    
>>
>Попробуйте хотя бы квотить по человечески.
>  
>
тут есть над чем поразмыслить. Я постараюсь.

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] glib2/libgtk+2 API changes

[Yuri N. Sedunov]

On Среда 17 Ноябрь 2004 16:37, Ildar Mulyukov wrote:
> Yuri N. Sedunov wrote:
<skip>
> >>>>>>
> >>>>>>Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?
> >>>>>
> >>>>>"в данном случае зависимости пакетов"  должны препятствовать
> >>>>> "частичному обновлению M24 пакетами из Сизифа с получением
> >>>>> неработающих
> >>>>>программ, которые в полностью обновлённой системе работают"
> >>>>
> >>>>То есть багу надо вешать на gaim и ещё сотню программ, чтобы все
> >>>>мэйнтейнеры прописали Require?
> >>>
> >>>Список из сотни программ, пожалуйста. Или хотя бы еще парочку, для
> >>> которых потребуется прописать такие зависимости.
> >>
> >>Хорошо, хорошо. Я погорячился. Но такие программы появятся при следующей
> >>же пересборке [этих программ], насколько я понимаю.
> >
> >Если таковые программы вдруг появяться, специально для Вас есть
> > bugzilla.altlinux.org.
>
> Я понимаю, что поступаю неправильно и даже неэтично по отношению к
> сообществу ALTLinux, но так получилось, что я не могу сейчас тратить
> время на переход XFree86->x.org, а без этого дистапгрейд невозможен.
> Извините.

Вполне возможен, надо поставить на холд XFree86. Сам так жил довольно 
продолжительное время.

-- 
Yuri N. Sedunov
11/17/04 16:39:45

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 15:43 Yuri N. Sedunov написал(a):
> On Среда 17 Ноябрь 2004 16:37, Ildar Mulyukov wrote:
> > Yuri N. Sedunov wrote:
>
> <skip>
>
> > >>>>>>Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?
> > >>>>>
> > >>>>>"в данном случае зависимости пакетов"  должны препятствовать
> > >>>>> "частичному обновлению M24 пакетами из Сизифа с получением
> > >>>>> неработающих
> > >>>>>программ, которые в полностью обновлённой системе работают"
> > >>>>
> > >>>>То есть багу надо вешать на gaim и ещё сотню программ, чтобы все
> > >>>>мэйнтейнеры прописали Require?
> > >>>
> > >>>Список из сотни программ, пожалуйста. Или хотя бы еще парочку, для
> > >>> которых потребуется прописать такие зависимости.
> > >>
> > >>Хорошо, хорошо. Я погорячился. Но такие программы появятся при
> > >> следующей же пересборке [этих программ], насколько я понимаю.
> > >
> > >Если таковые программы вдруг появяться, специально для Вас есть
> > > bugzilla.altlinux.org.
> >
> > Я понимаю, что поступаю неправильно и даже неэтично по отношению к
> > сообществу ALTLinux, но так получилось, что я не могу сейчас тратить
> > время на переход XFree86->x.org, а без этого дистапгрейд невозможен.
> > Извините.
>
> Вполне возможен, надо поставить на холд XFree86. Сам так жил довольно
> продолжительное время.

Ага, щаз! Если поставить XFree86 на холд, то даже transcod и ogmtools не 
обновишь, не говоря уже о KDE :(

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

> > > я не могу сейчас тратить
> > > время на переход XFree86->x.org, а без этого дистапгрейд невозможен.
> > Вполне возможен, надо поставить на холд XFree86. Сам так жил довольно
> > продолжительное время.
> Ага, щаз! Если поставить XFree86 на холд, то даже transcod и ogmtools не
> обновишь, не говоря уже о KDE :(
ходят слухи что _сейчас_ уже можно смело брать и обновляться на xorg.

-- 
Regards, Nick S. Grechukh
NSG1-UANIC
network administrator at many places :-)

=== ALT Linux fortune: ========================
[...] чем меньше лишних зависимостей, тем быстрее работают
librpm и apt-get.
  -- ldv in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 15:54 Nick S. Grechukh написал(a):
> > > > я не могу сейчас тратить
> > > > время на переход XFree86->x.org, а без этого дистапгрейд невозможен.
> > >
> > > Вполне возможен, надо поставить на холд XFree86. Сам так жил довольно
> > > продолжительное время.
> >
> > Ага, щаз! Если поставить XFree86 на холд, то даже transcod и ogmtools не
> > обновишь, не говоря уже о KDE :(
>
> ходят слухи что _сейчас_ уже можно смело брать и обновляться на xorg.

переходить != обновляться... Ещё вопрос - зачем переходить (если исходить из 
того, что xorg это не "новый XFree86", а ещё одна реализация X Window 
System)?

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

В сообщении от Среда 17 Ноябрь 2004 16:02 led@ukr-fin.com.ua написал(a):
> > ходят слухи что _сейчас_ уже можно смело брать и обновляться на xorg.
>
> переходить != обновляться... Ещё вопрос - зачем переходить (если исходить
> из того, что xorg это не "новый XFree86", а ещё одна реализация X Window
> System)?
xorg это "новый xfree86". это форк последнего релиза xfree86 4.3. поскольку 
"нового xfree" у нас точно не будет, и все уже съехали на xorg, думайте сами. 
в принципе смело можете считать xorg = xfree 4.4.

-- 
Regards, Nick S. Grechukh
NSG1-UANIC
network administrator at many places :-)

=== ALT Linux fortune: ========================
Xft2 будет одной из заметных features наших новых дистрибутивов.
  -- aen in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 16:09 Nick S. Grechukh написал(a):
> В сообщении от Среда 17 Ноябрь 2004 16:02 led@ukr-fin.com.ua написал(a):
> > > ходят слухи что _сейчас_ уже можно смело брать и обновляться на xorg.
> >
> > переходить != обновляться... Ещё вопрос - зачем переходить (если исходить
> > из того, что xorg это не "новый XFree86", а ещё одна реализация X Window
> > System)?
>
> xorg это "новый xfree86".
Это не так.

> это форк последнего релиза xfree86 4.3.
А beep - это форк xmms. Ну и?

> поскольку  
> "нового xfree" у нас точно не будет,
Ой ли? СтОит ли бросаться такими категорическими заявлениями? Можно 
более-менее уверенно сказать, что в дистрибутиве и в репозитарии будет хоть 
какая-то реализация X Window, а вот какая - лучше ни чем не клястся...

> и все уже съехали на xorg,
"все мы" - ещё не значит ВСЕ.

> думайте  
> сами. в принципе смело можете считать xorg = xfree 4.4.
см. выше - почему я не могу так считать...

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

В сообщении от Среда 17 Ноябрь 2004 16:21 led@ukr-fin.com.ua написал(a):
> > это форк последнего релиза xfree86 4.3.
> А beep - это форк xmms. Ну и?
ни разу не форк, а порт на gtk2.
> > "нового xfree" у нас точно не будет,
а у кого он сейчас есть?

> > сами. в принципе смело можете считать xorg = xfree 4.4.
> см. выше - почему я не могу так считать...
по реализации это буквально он и есть. и на данный момент форк (пока?) 
достаточно близкий.

переход был недостаточно аккуратный, наблюдались отдельные траблы. но на то он 
и сизиф. но _сейчас_ можно смело обновляться.
вполне м.б, что никаких действий по переходу от вас не потребуется.

зы. а сколько разговоров было на тему "да когда ж у нас тоже будет xorg"...

-- 
Regards, Nick S. Grechukh
NSG1-UANIC
network administrator at many places :-)

=== ALT Linux fortune: ========================
Я не улавливаю, зачем про каждый новый пакет спрашивать incoming@?
  -- ldv in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 16:39 Nick S. Grechukh написал(a):
> В сообщении от Среда 17 Ноябрь 2004 16:21 led@ukr-fin.com.ua написал(a):
> > > это форк последнего релиза xfree86 4.3.
> >
> > А beep - это форк xmms. Ну и?
>
> ни разу не форк, а порт на gtk2.
>
> > > "нового xfree" у нас точно не будет,
>
> а у кого он сейчас есть?
>
> > > сами. в принципе смело можете считать xorg = xfree 4.4.
> >
> > см. выше - почему я не могу так считать...
>
> по реализации это буквально он и есть. и на данный момент форк (пока?)
> достаточно близкий.
>
> переход был недостаточно аккуратный, наблюдались отдельные траблы. но на то
> он и сизиф. но _сейчас_ можно смело обновляться.
> вполне м.б, что никаких действий по переходу от вас не потребуется.
>
> зы. а сколько разговоров было на тему "да когда ж у нас тоже будет xorg"...

Хотелось... Но не ВМЕСТО, а ВМЕСТЕ.

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[Anton Farygin]

Nick S. Grechukh wrote:
> В сообщении от Среда 17 Ноябрь 2004 16:02 led@ukr-fin.com.ua написал(a):
> 
>>>ходят слухи что _сейчас_ уже можно смело брать и обновляться на xorg.
>>
>>переходить != обновляться... Ещё вопрос - зачем переходить (если исходить
>>из того, что xorg это не "новый XFree86", а ещё одна реализация X Window
>>System)?
> 
> xorg это "новый xfree86". это форк последнего релиза xfree86 4.3. поскольку 
> "нового xfree" у нас точно не будет, и все уже съехали на xorg, думайте сами. 
> в принципе смело можете считать xorg = xfree 4.4.

К сожалению (для кого-то к радости, а для владельцев видеокарт от ATI - 
к сожалению), xorg 6.8.x уже намного больше чем xfree 4.4.

Rgds,
Rider

Re: [sisyphus] glib2/libgtk+2 API changes

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Wed, Nov 17, 2004 at 04:02:25PM +0200, led@ukr-fin.com.ua wrote:
> переходить != обновляться... Ещё вопрос - зачем переходить (если исходить из 
> того, что xorg это не "новый XFree86", а ещё одна реализация X Window 
> System)?
Как не новый? 4.4 это, насколько я понимаю. Фактически.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Если Вы не будете вообще ничего качать,
то у Вас никогда не будет никакого признака
чего бы то ни было :-)
		-- zerg in sisyphus@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 16:57 Andrey Rahmatullin написал(a):
> On Wed, Nov 17, 2004 at 04:02:25PM +0200, led@ukr-fin.com.ua wrote:
> > переходить != обновляться... Ещё вопрос - зачем переходить (если исходить
> > из того, что xorg это не "новый XFree86", а ещё одна реализация X Window
> > System)?
>
> Как не новый? 4.4 это, насколько я понимаю. Фактически.

Фактически, X Window должен быть и в Африке X Window, если она X11R6. С xorg в 
Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая зависимость 
именно на xorg :(

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[Aleksey Novodvorsky]

led@ukr-fin.com.ua пишет:

>В сообщении от Среда 17 Ноябрь 2004 16:57 Andrey Rahmatullin написал(a):
>  
>
>>On Wed, Nov 17, 2004 at 04:02:25PM +0200, led@ukr-fin.com.ua wrote:
>>    
>>
>>>переходить != обновляться... Ещё вопрос - зачем переходить (если исходить
>>>из того, что xorg это не "новый XFree86", а ещё одна реализация X Window
>>>System)?
>>>      
>>>
>>Как не новый? 4.4 это, насколько я понимаю. Фактически.
>>    
>>
>
>Фактически, X Window должен быть и в Африке X Window, если она X11R6.
>
Это означает стандартизацию сетевых протоколов X11, не более.

> С xorg в 
>Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая зависимость 
>именно на xorg :(
>  
>
Не просто на xorg, а на конкретную сборку xorg, -- это естественно.

Rgrds, Алексей

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 17:39 Aleksey Novodvorsky написал(a):
> led@ukr-fin.com.ua пишет:
> >В сообщении от Среда 17 Ноябрь 2004 16:57 Andrey Rahmatullin написал(a):
> >>On Wed, Nov 17, 2004 at 04:02:25PM +0200, led@ukr-fin.com.ua wrote:
> >>>переходить != обновляться... Ещё вопрос - зачем переходить (если
> >>> исходить из того, что xorg это не "новый XFree86", а ещё одна
> >>> реализация X Window System)?
> >>
> >>Как не новый? 4.4 это, насколько я понимаю. Фактически.
> >
> >Фактически, X Window должен быть и в Африке X Window, если она X11R6.
>
> Это означает стандартизацию сетевых протоколов X11, не более.

А API?

> > С xorg в
> >Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая
> > зависимость именно на xorg :(
>
> Не просто на xorg, а на конкретную сборку xorg, -- это естественно.
Если следовать этому правилу, то закрытого софта под X Window не существует и 
он невозможен в принципе.

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[Aleksey Novodvorsky]

led@ukr-fin.com.ua пишет:

>>>С xorg в
>>>Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая
>>>зависимость именно на xorg :(
>>>      
>>>
>>Не просто на xorg, а на конкретную сборку xorg, -- это естественно.
>>    
>>
>Если следовать этому правилу, то закрытого софта под X Window не существует и 
>он невозможен в принципе.
>
>  
>
Возможен, так как он (частично) линкуется статически.
С каждым случаем зависимости на xorg надо разбираться, она может быть 
излишней, но вовсе не обязательно.

Rgrds, Алексей

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 17:53 Aleksey Novodvorsky написал(a):
> led@ukr-fin.com.ua пишет:
> >>>С xorg в
> >>>Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая
> >>>зависимость именно на xorg :(
> >>
> >>Не просто на xorg, а на конкретную сборку xorg, -- это естественно.
> >
> >Если следовать этому правилу, то закрытого софта под X Window не
> > существует и он невозможен в принципе.
>
> Возможен, так как он (частично) линкуется статически.
> С каждым случаем зависимости на xorg надо разбираться, она может быть
> излишней, но вовсе не обязательно.

Похоже, что так и есть (в смысле - излишние зависимости). По крайней мере я 
пересобирал последние KDE, transcode etc. c XFree86 4.3 - всё нормально 
работает. Думаю и на XFree 3.3.6 соберётся и будет работать, и на MetroX...

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 17:58 led@ukr-fin.com.ua написал(a):
> В сообщении от Среда 17 Ноябрь 2004 17:53 Aleksey Novodvorsky написал(a):
> > led@ukr-fin.com.ua пишет:
> > >>>С xorg в
> > >>>Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая
> > >>>зависимость именно на xorg :(
> > >>
> > >>Не просто на xorg, а на конкретную сборку xorg, -- это естественно.
> > >
> > >Если следовать этому правилу, то закрытого софта под X Window не
> > > существует и он невозможен в принципе.
> >
> > Возможен, так как он (частично) линкуется статически.
> > С каждым случаем зависимости на xorg надо разбираться, она может быть
> > излишней, но вовсе не обязательно.
>
> Похоже, что так и есть (в смысле - излишние зависимости). По крайней мере я
> пересобирал последние KDE, transcode etc. c XFree86 4.3 - всё нормально
> работает. Думаю и на XFree 3.3.6 соберётся и будет работать, и на MetroX...

Сорри, прогнал...
Пересобранный естественно будет работать;)
Я имел ввиду, что собранный правильно будет работать без перекомпиляции на 
всех нормальных реализациях X11R6.

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]

В сообщении от 17 Ноябрь 2004 19:02 led@ukr-fin.com.ua написал(a):
> В сообщении от Среда 17 Ноябрь 2004 17:58 led@ukr-fin.com.ua написал(a):
> > В сообщении от Среда 17 Ноябрь 2004 17:53 Aleksey Novodvorsky написал(a):
> > > led@ukr-fin.com.ua пишет:
> > > >>>С xorg в
> > > >>>Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая
> > > >>>зависимость именно на xorg :(
> > > >>
> > > >>Не просто на xorg, а на конкретную сборку xorg, -- это естественно.
> > > >
> > > >Если следовать этому правилу, то закрытого софта под X Window не
> > > > существует и он невозможен в принципе.
> > >
> > > Возможен, так как он (частично) линкуется статически.
> > > С каждым случаем зависимости на xorg надо разбираться, она может быть
> > > излишней, но вовсе не обязательно.
> >
> > Похоже, что так и есть (в смысле - излишние зависимости). По крайней мере
> > я пересобирал последние KDE, transcode etc. c XFree86 4.3 - всё нормально
> > работает. Думаю и на XFree 3.3.6 соберётся и будет работать, и на
> > MetroX...
>
> Сорри, прогнал...
> Пересобранный естественно будет работать;)
> Я имел ввиду, что собранный правильно будет работать без перекомпиляции на
> всех нормальных реализациях X11R6.

ага, щаааззз.... про сонеймы не забыли?

-- 
Valery V. Inozemtsev

Powered by ALT Linux Sisyphus (20041115)
ftp://ftp.altlinux.ru/pub/people/shrek/

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 18:06 Valery V. Inozemtsev написал(a):
> В сообщении от 17 Ноябрь 2004 19:02 led@ukr-fin.com.ua написал(a):
> > В сообщении от Среда 17 Ноябрь 2004 17:58 led@ukr-fin.com.ua написал(a):
> > > В сообщении от Среда 17 Ноябрь 2004 17:53 Aleksey Novodvorsky 
написал(a):
> > > > led@ukr-fin.com.ua пишет:
> > > > >>>С xorg в
> > > > >>>Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая
> > > > >>>зависимость именно на xorg :(
> > > > >>
> > > > >>Не просто на xorg, а на конкретную сборку xorg, -- это естественно.
> > > > >
> > > > >Если следовать этому правилу, то закрытого софта под X Window не
> > > > > существует и он невозможен в принципе.
> > > >
> > > > Возможен, так как он (частично) линкуется статически.
> > > > С каждым случаем зависимости на xorg надо разбираться, она может быть
> > > > излишней, но вовсе не обязательно.
> > >
> > > Похоже, что так и есть (в смысле - излишние зависимости). По крайней
> > > мере я пересобирал последние KDE, transcode etc. c XFree86 4.3 - всё
> > > нормально работает. Думаю и на XFree 3.3.6 соберётся и будет работать,
> > > и на MetroX...
> >
> > Сорри, прогнал...
> > Пересобранный естественно будет работать;)
> > Я имел ввиду, что собранный правильно будет работать без перекомпиляции
> > на всех нормальных реализациях X11R6.
>
> ага, щаааззз.... про сонеймы не забыли?

Нет, не забыли. Просто сонеймы при сборке нужно правильные использовать: не 
so.1.2.3.4.5.6.7, а so.1 (если собираемой софтине этого достаточно, а в 
данном случае так оно и есть). И зависимости прописывать не на пакеты, а на 
конкретные файлы libxxx.so.x. Хотя, лучше наверное не задумываться о таких 
"мелочах" и полагаться на autoconf :(

Led.

Re: [sisyphus] glib2/libgtk+2 API changes

[Andrei Bulava]

led@ukr-fin.com.ua пишет:
> В сообщении от Среда 17 Ноябрь 2004 18:06 Valery V. Inozemtsev написал(a):
>>
>>ага, щаааззз.... про сонеймы не забыли?
> 
> 
> Нет, не забыли. Просто сонеймы при сборке нужно правильные использовать: не 
> so.1.2.3.4.5.6.7, а so.1 (если собираемой софтине этого достаточно, а в 
> данном случае так оно и есть). И зависимости прописывать не на пакеты, а на 
> конкретные файлы libxxx.so.x.

Хм, до сегодняшнего дня я был уверен, что /usr/lib/rpm/find-requires 
именно так и поступает с разделяемыми библиотеками. Посмотрел текст 
функции FindLibReqs() в упомянутом выше скрипте - вроде так и есть.

Беда в том (и об этом сегодня уже говорили в этом топике), что не все 
программисты корректно отражают изменения ABI (не путать с API!) в 
изменениях soname.

P.S. BTW, имя файла библиотеки libfoo.so.1.2.3.4 не гарантирует, что 
soname библиотеки будет libfoo.so.1, если я правильно понял ld(1).

-- 
// AB1002-UANIC

Re: [sisyphus] lib API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

On Wed, Nov 17, 2004 at 06:41:57PM +0200, Andrei Bulava wrote:
> P.S. BTW, имя файла библиотеки libfoo.so.1.2.3.4 не гарантирует, что 
> soname библиотеки будет libfoo.so.1, если я правильно понял ld(1).

Имя файла вообще ничего не гарантирует.
См. напр. libutempter.
Файл по имени libfoo.so.1.2.3.4 не обязан быть библиотекой.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] lib API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 18:48 Dmitry V. Levin написал(a):
> On Wed, Nov 17, 2004 at 06:41:57PM +0200, Andrei Bulava wrote:
> > P.S. BTW, имя файла библиотеки libfoo.so.1.2.3.4 не гарантирует, что
> > soname библиотеки будет libfoo.so.1, если я правильно понял ld(1).
>
> Имя файла вообще ничего не гарантирует.
> См. напр. libutempter.
> Файл по имени libfoo.so.1.2.3.4 не обязан быть библиотекой.

Вопрос в том, что на подобные libfoo.so.1.2.3.4 стоят жёсткие зависимости в 
пакетах, поэтому на систему с XFree86 они и не ставятся корректно... 
Поставленные некорректно работают нормально (но перестаёт работать apt, 
естественно)

Led.

Re: [sisyphus] lib API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Wed, Nov 17, 2004 at 06:55:37PM +0200, led@ukr-fin.com.ua wrote:
> В сообщении от Среда 17 Ноябрь 2004 18:48 Dmitry V. Levin написал(a):
> > On Wed, Nov 17, 2004 at 06:41:57PM +0200, Andrei Bulava wrote:
> > > P.S. BTW, имя файла библиотеки libfoo.so.1.2.3.4 не гарантирует, что
> > > soname библиотеки будет libfoo.so.1, если я правильно понял ld(1).
> >
> > Имя файла вообще ничего не гарантирует.
> > См. напр. libutempter.
> > Файл по имени libfoo.so.1.2.3.4 не обязан быть библиотекой.
> 
> Вопрос в том, что на подобные libfoo.so.1.2.3.4 стоят жёсткие зависимости в 

Например?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] lib API changes

[led]

В сообщении от Среда 17 Ноябрь 2004 19:06 Dmitry V. Levin написал(a):
> On Wed, Nov 17, 2004 at 06:55:37PM +0200, led@ukr-fin.com.ua wrote:
> > В сообщении от Среда 17 Ноябрь 2004 18:48 Dmitry V. Levin написал(a):
> > > On Wed, Nov 17, 2004 at 06:41:57PM +0200, Andrei Bulava wrote:
> > > > P.S. BTW, имя файла библиотеки libfoo.so.1.2.3.4 не гарантирует, что
> > > > soname библиотеки будет libfoo.so.1, если я правильно понял ld(1).
> > >
> > > Имя файла вообще ничего не гарантирует.
> > > См. напр. libutempter.
> > > Файл по имени libfoo.so.1.2.3.4 не обязан быть библиотекой.
> >
> > Вопрос в том, что на подобные libfoo.so.1.2.3.4 стоят жёсткие зависимости
> > в
>
> Например?

Например, libXaw.so.8

Led.

Re: [sisyphus] lib API changes

[Andrei Bulava]

led@ukr-fin.com.ua пишет:
> Например, libXaw.so.8

Что в этом криминального? В ALM 2.4 libXaw.so.7, в текущем Sisyphus - 
libXaw.so.8. Если авторы xorg изменили ABI этой библиотеки (и поменяли 
soname вследствие этого), то всё абсолютно корректно - приложения, 
слинкованные с libXaw.so.8 с большой долей вероятности будут иметь 
unresolved symbols при попытке запуска в системе с libXaw.so.7.

При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7 
тех же самых приложений пройдёт корректно. Но они будут 
двоично-несовместимы уже с сизифной libXaw.so.8.

-- 
// AB1002-UANIC

Re: [sisyphus] lib API changes

[led]

В сообщении от Четверг 18 Ноябрь 2004 16:22 Andrei Bulava написал(a):
> led@ukr-fin.com.ua пишет:
> > Например, libXaw.so.8
>
> Что в этом криминального? В ALM 2.4 libXaw.so.7, в текущем Sisyphus -
> libXaw.so.8. Если авторы xorg изменили ABI этой библиотеки (и поменяли
> soname вследствие этого), то всё абсолютно корректно - приложения,
> слинкованные с libXaw.so.8 с большой долей вероятности будут иметь
> unresolved symbols при попытке запуска в системе с libXaw.so.7.
>
> При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7
> тех же самых приложений пройдёт корректно. Но они будут
> двоично-несовместимы уже с сизифной libXaw.so.8.

Приложения корректно работают с libXaw.so.7 и я не верю Вам, что авторы 
transcode завязали свою софтину именно на libXaw.so.8.
Так понятнее? Тогда почему в сизифовском пакете transcode стоит жёсткая 
зависимость на libXaw.so.8?

Led.

Re: [sisyphus] lib API changes

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

В сообщении от Четверг 18 Ноябрь 2004 16:40 led@ukr-fin.com.ua написал(a):
 > При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7
> > тех же самых приложений пройдёт корректно. Но они будут
> > двоично-несовместимы уже с сизифной libXaw.so.8.
>
> Приложения корректно работают с libXaw.so.7 и я не верю Вам, что авторы
> transcode завязали свою софтину именно на libXaw.so.8.
сказано же, двоично несовместимы. пересборка пройдет нормально и поможет. 
> Так понятнее? Тогда почему в сизифовском пакете transcode стоит жёсткая
> зависимость на libXaw.so.8?
ну видимо потому что зависимости на .so ищутся автопилотом.
попробовать rpm -ivh --nodeps ? точно работать будет?

-- 
Regards, Nick S. Grechukh
NSG1-UANIC
network administrator at many places :-)

=== ALT Linux fortune: ========================
Я не уверен, что _exit_cleanup() имеет право возвращать управление.
  -- ldv in sisyphus@

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [sisyphus] lib API changes

[led]

В сообщении от Четверг 18 Ноябрь 2004 16:56 Nick S. Grechukh написал(a):
> В сообщении от Четверг 18 Ноябрь 2004 16:40 led@ukr-fin.com.ua написал(a):
>  > При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7
>  >
> > > тех же самых приложений пройдёт корректно. Но они будут
> > > двоично-несовместимы уже с сизифной libXaw.so.8.
> >
> > Приложения корректно работают с libXaw.so.7 и я не верю Вам, что авторы
> > transcode завязали свою софтину именно на libXaw.so.8.
>
> сказано же, двоично несовместимы. пересборка пройдет нормально и поможет.
>
> > Так понятнее? Тогда почему в сизифовском пакете transcode стоит жёсткая
> > зависимость на libXaw.so.8?
>
> ну видимо потому что зависимости на .so ищутся автопилотом.
> попробовать rpm -ivh --nodeps ? точно работать будет?

Точно работает

Led.

Re: [sisyphus] lib API changes

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Thu, Nov 18, 2004 at 04:40:14PM +0200, led@ukr-fin.com.ua wrote:
> Так понятнее? Тогда почему в сизифовском пакете transcode стоит жёсткая 
> зависимость на libXaw.so.8?
Сизифовый пакет собран с libXaw.so.8. См про ABI.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<drF_ckoff> я ж говорил уже неоднократно - я пока морально не готов
            пакаджером быть
<Voins> drF_ckoff, приезжай на фест, мы там тебя.... подготовим :)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] lib API changes

[led]

В сообщении от Четверг 18 Ноябрь 2004 16:22 Andrei Bulava написал(a):
> led@ukr-fin.com.ua пишет:
> > Например, libXaw.so.8
>
> Что в этом криминального? В ALM 2.4 libXaw.so.7, в текущем Sisyphus -
> libXaw.so.8. Если авторы xorg изменили ABI этой библиотеки (и поменяли
> soname вследствие этого), то всё абсолютно корректно - приложения,
> слинкованные с libXaw.so.8 с большой долей вероятности будут иметь
> unresolved symbols при попытке запуска в системе с libXaw.so.7.
>
> При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7
> тех же самых приложений пройдёт корректно. Но они будут
> двоично-несовместимы уже с сизифной libXaw.so.8.

А вот здесь поподробнее, плиз... Кто "они", и что значит "будут 
двоично-несовместимы"? Там что - вызовы из libXaw.so по абсолютному адресу 
происходят?

Led.

Re: [sisyphus] lib API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On Thu, Nov 18, 2004 at 04:43:15PM +0200, led@ukr-fin.com.ua wrote:
> В сообщении от Четверг 18 Ноябрь 2004 16:22 Andrei Bulava написал(a):
> > led@ukr-fin.com.ua пишет:
> > > Например, libXaw.so.8
> >
> > Что в этом криминального? В ALM 2.4 libXaw.so.7, в текущем Sisyphus -
> > libXaw.so.8. Если авторы xorg изменили ABI этой библиотеки (и поменяли
> > soname вследствие этого), то всё абсолютно корректно - приложения,
> > слинкованные с libXaw.so.8 с большой долей вероятности будут иметь
> > unresolved symbols при попытке запуска в системе с libXaw.so.7.
> >
> > При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7
> > тех же самых приложений пройдёт корректно. Но они будут
> > двоично-несовместимы уже с сизифной libXaw.so.8.
> 
> А вот здесь поподробнее, плиз... Кто "они", и что значит "будут 
> двоично-несовместимы"? Там что - вызовы из libXaw.so по абсолютному адресу 
> происходят?

Другими словами, вы спрашиваете, что такое ABI.  Посмотрите, пожалуйста,
словарь терминов.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

lib ABI changes (was: Re: [sisyphus] lib API changes)

[Andrei Bulava]

Dmitry V. Levin пишет:
> Другими словами, вы спрашиваете, что такое ABI.  Посмотрите, пожалуйста,
> словарь терминов.

А надо было с самого начала переименовывать топик в "glib2/libgtk+2 ABI 
changes" ;-)

-- 
// AB1002-UANIC

Re: [sisyphus] lib API changes

[Andrei Bulava]

led@ukr-fin.com.ua пишет:
> В сообщении от Четверг 18 Ноябрь 2004 16:22 Andrei Bulava написал(a):
> 
>>led@ukr-fin.com.ua пишет:
>>
>>>Например, libXaw.so.8
>>
>>Что в этом криминального? В ALM 2.4 libXaw.so.7, в текущем Sisyphus -
>>libXaw.so.8. Если авторы xorg изменили ABI этой библиотеки (и поменяли
>>soname вследствие этого), то всё абсолютно корректно - приложения,
>>слинкованные с libXaw.so.8 с большой долей вероятности будут иметь
>>unresolved symbols при попытке запуска в системе с libXaw.so.7.
>>
>>При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7
>>тех же самых приложений пройдёт корректно. Но они будут
>>двоично-несовместимы уже с сизифной libXaw.so.8.
> 
> 
> А вот здесь поподробнее, плиз... Кто "они", и что значит "будут 
> двоично-несовместимы"? Там что - вызовы из libXaw.so по абсолютному адресу 
> происходят?

Попытаюсь объяснить на пальцАх (подробнее можно прочитать в упомянутом 
надцать раз "How to Write Shared Libraries").

Есть библиотека libfoo.so (это soname - попадаются и такие библиотеки!) 
с API из единственной функции bar ( int ) и есть приложение с вызовом 
функции bar ( x ), динамически слинкованное с библиотекой libfoo.so. В 
один прекрасный день девелоперы libfoo решают, что надо изменить 
сигнатуру функции bar с bar ( int ) на bar ( int, int ), при этом старая 
функция bar ( int ) теперь выражается через bar ( int, int ) как bar ( 
int, <константа >). Естественно, чтобы не ломать API, в заголовочных 
файлах libfoo добавляется макрос, подменяющий на этапе препроцессинга 
все вызовы bar ( x ) на bar ( x, <константа> ) - это даёт гарантию, что 
приложения с вызовом bar ( x ) будут без проблем компилироваться с 
"новой" libfoo.so.

Вот и имеем изменение ABI в то время как API "новой" libfoo.so есть 
надмножество API "старой" libfoo.so: теперь приложение, динамически 
слинкованное со "старой" libfoo.so, при запуске с "новой" libfoo.so 
будет иметь неразрешённый символ - ибо двоичный файл "новой" библиотеки 
вообще не содержит функции bar ( int ) !!! И наоборот - если 
перекомпилировать приложение с "новой" libfoo.so - оно не запустится со 
старой, теперь из-за отсутствия функции bar ( int, int ) !!!

Вот тогда и было придумано соглашение о добавлении в soname цифр, 
отражающих изменение ABI, чтобы избежать появления dll hell. Это даёт 
возможность менеджерам пакетов автоматически отслеживать двоичную 
целостность системы без запуска всех исполняемых ELF-файлов вручную.

Так понятнее?

-- 
// AB1002-UANIC

Re: [sisyphus] lib API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On Thu, Nov 18, 2004 at 05:36:20PM +0200, Andrei Bulava wrote:
> Вот и имеем изменение ABI в то время как API "новой" libfoo.so есть 
> надмножество API "старой" libfoo.so: теперь приложение, динамически 
> слинкованное со "старой" libfoo.so, при запуске с "новой" libfoo.so 
> будет иметь неразрешённый символ - ибо двоичный файл "новой" библиотеки 
> вообще не содержит функции bar ( int ) !!! И наоборот - если 
> перекомпилировать приложение с "новой" libfoo.so - оно не запустится со 
> старой, теперь из-за отсутствия функции bar ( int, int ) !!!

Это, скажем, в C++ всё будет так хорошо, как вы говорите, и при изменении
сигнатуры функции dynamic linker не даст этому безобразию запуститься.

С библиотеками и программами на C всё гораздо хуже, поскольку сигнатуры
функций содержат лишь имена.  При этом вызванная старой программой функция
из новой библиотеки в вашем примере в качестве второго аргумента получит
мусор со стека, со всеми вытекающими.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] lib API changes

[led]

В сообщении от Четверг 18 Ноябрь 2004 17:36 Andrei Bulava написал(a):
> led@ukr-fin.com.ua пишет:
> > В сообщении от Четверг 18 Ноябрь 2004 16:22 Andrei Bulava написал(a):
> >>led@ukr-fin.com.ua пишет:
> >>>Например, libXaw.so.8
> >>
> >>Что в этом криминального? В ALM 2.4 libXaw.so.7, в текущем Sisyphus -
> >>libXaw.so.8. Если авторы xorg изменили ABI этой библиотеки (и поменяли
> >>soname вследствие этого), то всё абсолютно корректно - приложения,
> >>слинкованные с libXaw.so.8 с большой долей вероятности будут иметь
> >>unresolved symbols при попытке запуска в системе с libXaw.so.7.
> >>
> >>При этом API могло и не менятся, т.е. пересборка в среде с libXaw.so.7
> >>тех же самых приложений пройдёт корректно. Но они будут
> >>двоично-несовместимы уже с сизифной libXaw.so.8.
> >
> > А вот здесь поподробнее, плиз... Кто "они", и что значит "будут
> > двоично-несовместимы"? Там что - вызовы из libXaw.so по абсолютному
> > адресу происходят?
>
> Попытаюсь объяснить на пальцАх (подробнее можно прочитать в упомянутом
> надцать раз "How to Write Shared Libraries").
>
> Есть библиотека libfoo.so (это soname - попадаются и такие библиотеки!)
> с API из единственной функции bar ( int ) и есть приложение с вызовом
> функции bar ( x ), динамически слинкованное с библиотекой libfoo.so. В
> один прекрасный день девелоперы libfoo решают, что надо изменить
> сигнатуру функции bar с bar ( int ) на bar ( int, int ), при этом старая
> функция bar ( int ) теперь выражается через bar ( int, int ) как bar (
> int, <константа >). Естественно, чтобы не ломать API, в заголовочных
> файлах libfoo добавляется макрос, подменяющий на этапе препроцессинга
> все вызовы bar ( x ) на bar ( x, <константа> ) - это даёт гарантию, что
> приложения с вызовом bar ( x ) будут без проблем компилироваться с
> "новой" libfoo.so.
>
> Вот и имеем изменение ABI в то время как API "новой" libfoo.so есть
> надмножество API "старой" libfoo.so: теперь приложение, динамически
> слинкованное со "старой" libfoo.so, при запуске с "новой" libfoo.so
> будет иметь неразрешённый символ - ибо двоичный файл "новой" библиотеки
> вообще не содержит функции bar ( int ) !!! И наоборот - если
> перекомпилировать приложение с "новой" libfoo.so - оно не запустится со
> старой, теперь из-за отсутствия функции bar ( int, int ) !!!
>
> Вот тогда и было придумано соглашение о добавлении в soname цифр,
> отражающих изменение ABI, чтобы избежать появления dll hell. Это даёт
> возможность менеджерам пакетов автоматически отслеживать двоичную
> целостность системы без запуска всех исполняемых ELF-файлов вручную.
>
> Так понятнее?

Это понятно:) Вопрос не в терминологии, а в практике: т.н. "автоматика" 
поставила зависимость на libXaw.so.8. Вы уверены, что это правильно? ИМХО 
нет...

Led.

[sisyphus] Re: lib API changes

[Michael Shigorin]

On Thu, Nov 18, 2004 at 06:06:42PM +0200, led@ukr-fin.com.ua wrote:
> Это понятно:) Вопрос не в терминологии, а в практике: т.н.
> "автоматика" поставила зависимость на libXaw.so.8. Вы уверены,
> что это правильно? ИМХО нет...

На чём основывается ХО? (автоматика -- на символах в бинарниках
AFAIK)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] lib ABI changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

On Thu, Nov 18, 2004 at 06:06:42PM +0200, led@ukr-fin.com.ua wrote:
[...]
> Это понятно:) Вопрос не в терминологии,

Извините, но из-за непонимания терминологии берутся такие вопросы.

> а в практике: т.н. "автоматика" 
> поставила зависимость на libXaw.so.8. Вы уверены, что это правильно? ИМХО 
> нет...

Ну хорошо, смотрите:

$ ls -1 -og /usr/X11R6/lib/libXaw.so*
lrwxrwxrwx  1     13 Ноя 18 19:14 /usr/X11R6/lib/libXaw.so -> libXaw.so.8.0
lrwxrwxrwx  1     13 Ноя 18 19:14 /usr/X11R6/lib/libXaw.so.6 -> libXaw.so.6.1
-rw-r--r--  1 256816 Ноя 12 15:46 /usr/X11R6/lib/libXaw.so.6.1
lrwxrwxrwx  1     13 Ноя 18 19:14 /usr/X11R6/lib/libXaw.so.7 -> libXaw.so.7.0
-rw-r--r--  1 367056 Ноя 12 15:46 /usr/X11R6/lib/libXaw.so.7.0
lrwxrwxrwx  1     13 Ноя 18 19:14 /usr/X11R6/lib/libXaw.so.8 -> libXaw.so.8.0
-rw-r--r--  1 375024 Ноя 12 15:46 /usr/X11R6/lib/libXaw.so.8.0

Это значит, что _все_ новособранные программы, линкующиеся с -lXaw, будут
линковаться именно с libXaw.so.8 (а программы, собранные ранее, по
прежнему будут пользоваться libXaw.so.6 и libXaw.so.7).

Если вы считаете, что это не правильно, значит, вы не понимаете предмет в
достаточной степени, чтобы продолжать разговор дальше.

Предположим, что это понятно.  Тогда смотрите дальше:

$ readelf -d /usr/X11R6/bin/xterm |fgrep libXaw
 0x00000001 (NEEDED)                     Shared library: [libXaw.so.8]

Всё ещё непонятно?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: X dependencies (was: glib2/libgtk+2 API changes)

[Mikhail Zabaluev]

В Срд, 17/11/2004 в 19:06 +0300, Valery V. Inozemtsev пишет:
> > Я имел ввиду, что собранный правильно будет работать без перекомпиляции на
> > всех нормальных реализациях X11R6.

На самом деле непонятно, почему у нас зависимости делаются на xorg, а не
на виртуальный X11R6, который бы давали и XFree86, и xorg, и
гипотетический MetroX...

> ага, щаааззз.... про сонеймы не забыли?

Об этом заботится автоматика.

Re: [sisyphus] Re: X dependencies (was: glib2/libgtk+2 API changes)

[led]

В сообщении от Четверг 18 Ноябрь 2004 02:42 Mikhail Zabaluev написал(a):
> В Срд, 17/11/2004 в 19:06 +0300, Valery V. Inozemtsev пишет:
> > > Я имел ввиду, что собранный правильно будет работать без перекомпиляции
> > > на всех нормальных реализациях X11R6.
>
> На самом деле непонятно, почему у нас зависимости делаются на xorg, а не
> на виртуальный X11R6, который бы давали и XFree86, и xorg, и
> гипотетический MetroX...
Об этом уже третий раз разговор поднимаю... Никто так и не ответил...

>
> > ага, щаааззз.... про сонеймы не забыли?
>
> Об этом заботится автоматика.

Если автоматика "заботится" не совсем корректно - нужно или исправлять руками, 
или править автоматику, а не спихивать всё на неё, ИМХО...

Led.

[sisyphus] Re: X dependencies (was: glib2/libgtk+2 API changes)

[Michael Shigorin]

On Thu, Nov 18, 2004 at 04:47:25PM +0200, led@ukr-fin.com.ua wrote:
> > На самом деле непонятно, почему у нас зависимости делаются на
> > xorg, а не на виртуальный X11R6, который бы давали и XFree86,
> > и xorg, и гипотетический MetroX...
> Об этом уже третий раз разговор поднимаю... Никто так и не ответил...

Потому что это всё разговоры и теория, а на практике достаточной
заинтересованности не оказалось.

Хотя то, что не ожидали именно _замены_ многие (я в том числе) --
факт.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: X dependencies (was: glib2/libgtk+2 API changes)

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

В сообщении от Четверг 18 Ноябрь 2004 17:25 Michael Shigorin написал(a):
> Хотя то, что не ожидали именно _замены_ многие (я в том числе) --
> факт.
и опять же, заклинание "это ж сизиф" (c) оправдывает эту циничную замену. 
"я не жалуюсь, но так оно и есть" (c) ослик Иа.

-- 
Regards, Nick S. Grechukh
NSG1-UANIC
network administrator at many places :-)

=== ALT Linux fortune: ========================
Мастер достоин того, чтобы ради него купить DVD :)
  -- mithraen in community@

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [sisyphus] Re: X dependencies

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On Thu, Nov 18, 2004 at 05:25:33PM +0200, Michael Shigorin wrote:
> On Thu, Nov 18, 2004 at 04:47:25PM +0200, led@ukr-fin.com.ua wrote:
> > > На самом деле непонятно, почему у нас зависимости делаются на
> > > xorg, а не на виртуальный X11R6, который бы давали и XFree86,
> > > и xorg, и гипотетический MetroX...
> > Об этом уже третий раз разговор поднимаю... Никто так и не ответил...
> 
> Потому что это всё разговоры и теория, а на практике достаточной
> заинтересованности не оказалось.

Думаю что и не окажется.

> Хотя то, что не ожидали именно _замены_ многие (я в том числе) --
> факт.

А следовало ожидать.  Если бы в репозитарии сохранился, скажем, пакет
XFree86-libs, то это не остановило бы процесс перехода на Xorg ввиду
изменения ABI, сопровождающегося изменением soname.

Другими словами, Xorg следует рассматривать с практической точки зрения
как новую версию XFree86, которая, разумеется, одновременно со старой
очень сложно уживается.

Если вам нужен XFree86, вы можете взять пакеты из ALM2.4.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: X dependencies

[Andrei Bulava]

Dmitry V. Levin пишет:

<skip/>

> Если вам нужен XFree86, вы можете взять пакеты из ALM2.4.

И настроить сборочную станцию для пересборки Сизифа в среде с XFree86.

Конечно, пересобирать нужно будет не все пакеты, а только те, что
двоично несовместимы с Сизифом.

Что, однако, не спасёт от периодических unresolved symbols с последующей
пересборкой пакетов, которые не по вине  разработчиков ALT Linux
фактически являются двоично-несовместимыми, но факт такой
несовместимости невозможно отследить автоматически

P.S. Это длиннющее обсуждение с многочисленными ответвлениями началось 
именно с проблемы двоичной несовместимости, т.е. несовместимости ABI.

-- 
// AB1002-UANIC

Re: [sisyphus] Re: X dependencies

[led]

В сообщении от Четверг 18 Ноябрь 2004 17:52 Andrei Bulava написал(a):
> Dmitry V. Levin пишет:
>
> <skip/>
>
> > Если вам нужен XFree86, вы можете взять пакеты из ALM2.4.
>
> И настроить сборочную станцию для пересборки Сизифа в среде с XFree86.
>
> Конечно, пересобирать нужно будет не все пакеты, а только те, что
> двоично несовместимы с Сизифом.
>
> Что, однако, не спасёт от периодических unresolved symbols с последующей
> пересборкой пакетов, которые не по вине  разработчиков ALT Linux
> фактически являются двоично-несовместимыми, но факт такой
> несовместимости невозможно отследить автоматически
>
> P.S. Это длиннющее обсуждение с многочисленными ответвлениями началось
> именно с проблемы двоичной несовместимости, т.е. несовместимости ABI.

Практический пример этой двоичной несовместимости в сизифе так никто и не 
привёл (к сожалению)...

Led.

Re: [sisyphus] Re: X dependencies

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

led@ukr-fin.com.ua пишет:

>>>Если вам нужен XFree86, вы можете взять пакеты из ALM2.4.
>>
>>И настроить сборочную станцию для пересборки Сизифа в среде с XFree86.
>>
>>Конечно, пересобирать нужно будет не все пакеты, а только те, что
>>двоично несовместимы с Сизифом.
>>
>>Что, однако, не спасёт от периодических unresolved symbols с последующей
>>пересборкой пакетов, которые не по вине  разработчиков ALT Linux
>>фактически являются двоично-несовместимыми, но факт такой
>>несовместимости невозможно отследить автоматически
>>
>>P.S. Это длиннющее обсуждение с многочисленными ответвлениями началось
>>именно с проблемы двоичной несовместимости, т.е. несовместимости ABI.
> 
> 
> Практический пример этой двоичной несовместимости в сизифе так никто и не 
> привёл (к сожалению)...
А вы считаете, что всем больше нечем заняться, кроме как сидеть и искать
это?
Оно ведь может вылезти ДАЛЕКО не сразу после запуска проги!!!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: X dependencies

[Andrei Bulava]

Ivan Fedorov пишет:
> led@ukr-fin.com.ua пишет:

<skip/>

>>Практический пример этой двоичной несовместимости в сизифе так никто и не 
>>привёл (к сожалению)...

Без комментариев :-\

> 
> А вы считаете, что всем больше нечем заняться, кроме как сидеть и искать
> это?
> Оно ведь может вылезти ДАЛЕКО не сразу после запуска проги!!!

Полностью согласен. Здесь имеет место анекдотическая ситуация с 
монашкой, шепчущей "бережёного Бог бережёт" и натягивающей презерватив 
на свечку. Ведь вызов одной-единственной (из многих!) функции с 
изменившейся сигнатурой может или а) вообще не делаться в каком-то 
конкретном приложении; или б) находиться в какой-нибудь условно 
выполняющейся конструкции.

ldv@ привёл пример последствий вызова функции из библиотеки с 
изменившимся ABI. Спасибо, мне даже одного _такого_ (попадания 
произвольного содержимого стека в аргументы вызываемой функции) и близко 
не надо.

P.S. Я пересобирал "на коленке" нужные мне приложения, попутно с нужными 
им для сборки вещами, из Сизифа под ALJ 1.1 практически до выхода ALJ 
2.0 - из-за того, что Сизиф перешёл на libpng.so.n+1 (если мне не 
изменяет склероз) по отношению к ALJ 1.1. Та система работает у меня по 
сей день уже как ALM 2.2. Правда, по причине значительного апгрейда 
железа ALM 2.4 ей уже не стать ;-)

-- 
// AB1002-UANIC

Re: [sisyphus] Re: X dependencies

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On Fri, Nov 19, 2004 at 12:27:27PM +0200, led@ukr-fin.com.ua wrote:
> В сообщении от Четверг 18 Ноябрь 2004 17:52 Andrei Bulava написал(a):
> > Dmitry V. Levin пишет:
> >
> > <skip/>
> >
> > > Если вам нужен XFree86, вы можете взять пакеты из ALM2.4.
> >
> > И настроить сборочную станцию для пересборки Сизифа в среде с XFree86.
> >
> > Конечно, пересобирать нужно будет не все пакеты, а только те, что
> > двоично несовместимы с Сизифом.
> >
> > Что, однако, не спасёт от периодических unresolved symbols с последующей
> > пересборкой пакетов, которые не по вине  разработчиков ALT Linux
> > фактически являются двоично-несовместимыми, но факт такой
> > несовместимости невозможно отследить автоматически
> >
> > P.S. Это длиннющее обсуждение с многочисленными ответвлениями началось
> > именно с проблемы двоичной несовместимости, т.е. несовместимости ABI.
> 
> Практический пример этой двоичной несовместимости в сизифе так никто и не 
> привёл (к сожалению)...

Оставляю поиск такого примера вам в качестве самостоятельного упражнения.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Aleksey Novodvorsky]

led@ukr-fin.com.ua пишет:

>В сообщении от Среда 17 Ноябрь 2004 17:53 Aleksey Novodvorsky написал(a):
>  
>
>>led@ukr-fin.com.ua пишет:
>>    
>>
>>>>>С xorg в
>>>>>Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая
>>>>>зависимость именно на xorg :(
>>>>>          
>>>>>
>>>>Не просто на xorg, а на конкретную сборку xorg, -- это естественно.
>>>>        
>>>>
>>>Если следовать этому правилу, то закрытого софта под X Window не
>>>существует и он невозможен в принципе.
>>>      
>>>
>>Возможен, так как он (частично) линкуется статически.
>>С каждым случаем зависимости на xorg надо разбираться, она может быть
>>излишней, но вовсе не обязательно.
>>    
>>
>
>Похоже, что так и есть (в смысле - излишние зависимости). По крайней мере я 
>пересобирал последние KDE, transcode etc. c XFree86 4.3 - всё нормально 
>работает. Думаю и на XFree 3.3.6 соберётся и будет работать, и на MetroX...
>
>  
>
Cоберется, вне всякого сомнения.
Речь здесь не о сборочной зависимости,  а о зависимости бинарной. Или нет?

Rgrds, Алексей

Re: [sisyphus] lib API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Wed, Nov 17, 2004 at 06:53:43PM +0300, Aleksey Novodvorsky wrote:
> led@ukr-fin.com.ua пишет:
> 
> >>>С xorg в
> >>>Сизифе это не наблюдается, вернее, с пакетами, у которых жёсткая
> >>>зависимость именно на xorg :(
> >>>
> >>Не просто на xorg, а на конкретную сборку xorg, -- это естественно.
> >>
> >Если следовать этому правилу, то закрытого софта под X Window не 
> >существует и он невозможен в принципе.
> >
> Возможен, так как он (частично) линкуется статически.

Кроме того, существует LSB, позволяющее в оговорённых случаях динамическую
линковку.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On Wed, Nov 17, 2004 at 03:54:44PM +0200, Nick S. Grechukh wrote:
> ходят слухи что _сейчас_ уже можно смело брать и обновляться на xorg.
Только вот на R300+, видимо, ускорение на данный момент впринципе
невозможно на ксорге.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Рассылка QA спама не есть частная инициатива.  Каждый раз он рассылается
по соглашению нескольких разработчиков в офисе, после уточнения благих
намерений.
		-- at in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

В сообщении от Среда 17 Ноябрь 2004 16:57 Andrey Rahmatullin написал(a):
> On Wed, Nov 17, 2004 at 03:54:44PM +0200, Nick S. Grechukh wrote:
> > ходят слухи что _сейчас_ уже можно смело брать и обновляться на xorg.
>
> Только вот на R300+, видимо, ускорение на данный момент впринципе
> невозможно на ксорге.

ничего не скажу, ибо исключительно nvidia. но я думаю, несчастному владельцу  
ati все скажет трафик comm@ за последние недели. а речь шла о том что 
человеку просто стремно.

-- 
Regards, Nick S. Grechukh
NSG1-UANIC
network administrator at many places :-)

=== ALT Linux fortune: ========================
Если увидите новость, что Compact вышел, значит я уже собираю KDE3.2
  -- zerg in sisyphus@

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Ildar Mulyukov]

led@ukr-fin.com.ua wrote:

>В сообщении от Среда 17 Ноябрь 2004 15:43 Yuri N. Sedunov написал(a):
>  
>
>>On Среда 17 Ноябрь 2004 16:37, Ildar Mulyukov wrote:
>>    
>>
>><skip/>
>>
>>    
>>
>>>Я понимаю, что поступаю неправильно и даже неэтично по отношению к
>>>сообществу ALTLinux, но так получилось, что я не могу сейчас тратить
>>>время на переход XFree86->x.org, а без этого дистапгрейд невозможен.
>>>Извините.
>>>      
>>>
>>Вполне возможен, надо поставить на холд XFree86. Сам так жил довольно
>>продолжительное время.
>>    
>>
>
>Ага, щаз! Если поставить XFree86 на холд, то даже transcod и ogmtools не 
>обновишь, не говоря уже о KDE :(
>  
>
именно это я имел в виду: нет смысла делать dist-upgrade, т.к. на x.org 
уже завязано "полсизифа" (в кавычках!)

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] glib2/libgtk+2 API changes

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Wed, Nov 17, 2004 at 01:31:04PM +0300, Yuri N. Sedunov wrote:
> Если таковые программы вдруг появяться, специально для Вас есть 
> bugzilla.altlinux.org.
Юра, #5479 разве не сюда же относится? 

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> И еще. нужна ли нам локализация на 19 языков? Без нее пакет будет хоть
> немного полегче:
Локализация всегда нужна. Неужели у нас выкидываются языки только
потому, что сборщики пакетов их не знают?
		-- slava in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Yuri N. Sedunov]

On Среда 17 Ноябрь 2004 16:54, Andrey Rahmatullin wrote:
> On Wed, Nov 17, 2004 at 01:31:04PM +0300, Yuri N. Sedunov wrote:
> > Если таковые программы вдруг появяться, специально для Вас есть
> > bugzilla.altlinux.org.
>
> Юра, #5479 разве не сюда же относится?
Это уже исправлено.
-- 
Yuri N. Sedunov
11/17/04 17:16:45

Re: [sisyphus] glib2/libgtk+2 API changes

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Wed, Nov 17, 2004 at 05:17:33PM +0300, Yuri N. Sedunov wrote:
> > Юра, #5479 разве не сюда же относится?
> Это уже исправлено.
Увидел после написания письма.
Кстати, все-таки это костыль :(

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Не надо совмещать простую задачу со сложной.
		-- ldv in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Andrei Bulava]

Andrey Rahmatullin пишет:
> On Wed, Nov 17, 2004 at 01:31:04PM +0300, Yuri N. Sedunov wrote:
> 
>>Если таковые программы вдруг появяться, специально для Вас есть 
>>bugzilla.altlinux.org.
> 
> Юра, #5479 разве не сюда же относится? 

Похоже, что сюда же.

"Не давайте больному костыли, лучше научите его ходить!" (c) - на мой 
взгляд, нужно жёстким излучением править ДНК разработчиков glib2, чтобы 
уважаемые разработчики всё-таки изучили для них же написанный "How to 
Write Shared Libraries". Иначе мы будем тратить время на борьбу с 
ветряными мельницами, более известными как "dll hell".

P.S. Хотя практика показывает, что "хочешь что-то сделать - сделай это 
сам" :-( Клонироваться что ли? ;-)

-- 
// AB1002-UANIC

Re: [sisyphus] glib2/libgtk+2 API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On Wed, Nov 17, 2004 at 04:32:47PM +0200, Andrei Bulava wrote:
[...]
> "Не давайте больному костыли, лучше научите его ходить!" (c) - на мой 
> взгляд, нужно жёстким излучением править ДНК разработчиков glib2, чтобы 

"Массовая гипноиндукция, позитиваная реморализация.  Гипноизлучатели на
трёх экваториальных спутниках..."


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] [OT] Re: glib2/libgtk+2 API changes

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Wed, Nov 17, 2004 at 05:56:07PM +0300, Dmitry V. Levin wrote:
> > "Не давайте больному костыли, лучше научите его ходить!" (c)
> > - на мой взгляд, нужно жёстким излучением править ДНК
> > разработчиков glib2, чтобы 
> "Массовая гипноиндукция, позитиваная реморализация.
> Гипноизлучатели на трёх экваториальных спутниках..."

А руль кому?

Давайте-ка с себя начнём, что ли.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] [OT] Re: glib2/libgtk+2 API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Wed, Nov 17, 2004 at 06:07:46PM +0200, Michael Shigorin wrote:
> On Wed, Nov 17, 2004 at 05:56:07PM +0300, Dmitry V. Levin wrote:
> > > "Не давайте больному костыли, лучше научите его ходить!" (c)
> > > - на мой взгляд, нужно жёстким излучением править ДНК
> > > разработчиков glib2, чтобы 
> > "Массовая гипноиндукция, позитиваная реморализация.
> > Гипноизлучатели на трёх экваториальных спутниках..."
> 
> А руль кому?
> 
> Давайте-ка с себя начнём, что ли.

Это же цитата была.  Ответ там тоже есть.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Ildar Mulyukov]

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 пакетами из Сизифа с получением неработающих
>>программ, которые в полностью обновлённой системе работают.
>>
>>Так что ответ для меня не очевиден, думаю что и для большинства
>>пользователей тоже.
>>    
>>
>Ответ содержится в твоем высказывании.
>
Но, в силу высказывания ЛДВ, он не очевиден, можно его озвучить?

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] glib2/libgtk+2 API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] glib2/libgtk+2 API changes

[Ildar Mulyukov]

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, все 
программы, собранные с новой библиотекой конфликтовали со старой 
библиотекой... Может быть новый тег для RPM? или сериал какой-нибудь 
задействовать? или ещё идеи?

Ильдар

-- 
Ildar  Mulyukov, 
  free SW designer/programmer
================================================
email: ildar@users.sourceforge.net
projects: http://os-development.sourceforge.net/
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================

Re: [sisyphus] lib API changes

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On Wed, Nov 17, 2004 at 01:14:55PM +0300, Ildar Mulyukov wrote:
> Вот бы волшебную палочку, чтобы с выходом новой версии API, все 
> программы, собранные с новой библиотекой конфликтовали со старой 
> библиотекой... Может быть новый тег для RPM? или сериал какой-нибудь 
> задействовать? или ещё идеи?

Про dsohowto было написано выше в треде.
К сожалению, большинство библиотекописателей этим правилам не следуют.

Например, в новых версиях zlib появляются новые функции, но, поскольку
не используется versioning, программа, решившаяся на использование этих
новых функций, рискует нарваться на undefined symbol при использовании
в более старой системе.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] gaim в свете последних перемен

[Vital Khilko]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Срд, 2004-11-17 at 11:17 +0300, Ildar Mulyukov wrote:

> Видимо, на 2.4. С чего 2.2???
Среды сизифа и мастера 2.4 уже очень сильно отличаются, для М2.4 будет
отдельное обновление.
> >>Спасибо за внимание.
> >>Если нужно, могу на бугзиллу повесить.
> >>    
> >>
> >повесьте, только не забудьте описать симптомы, ибо "практически не работает" мало чем может помочь.
> >  
> >
> Можно было бы обратить внимание не вложение в письмо.
> Повешу.
ага,вижу... но что-то оно меня поставило в тупик...


[-- Attachment #2: Гэтая частка паведамленьня падпісана электроным подпісам --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] gaim в свете последних перемен

[Andrei Bulava]

Vital Khilko пишет:
> On Срд, 2004-11-17 at 11:17 +0300, Ildar Mulyukov wrote:
>>
>>Можно было бы обратить внимание не вложение в письмо.
>>Повешу.
> 
> ага,вижу... но что-то оно меня поставило в тупик...

См. мою версию в параллельном ответвлении нити.

-- 
// AB1002-UANIC

Re: [sisyphus] gaim в свете последних перемен

[Mike Lykov]

В сообщении от Среда 17 Ноябрь 2004 12:17 Ildar Mulyukov написал:
> Кто-нибудь в курсе, бэкпортами кто-нибудь уже занимается? На 2.4? :-)

рассылка backports@altlinux.org.ua

-- 
Mike Lykov
Samara, "Vesna" parfum company, System administrator 

[sisyphus] Re: gaim в свете последних перемен

[Michael Shigorin]

On Wed, Nov 17, 2004 at 12:36:56PM +0400, Mike Lykov wrote:
> > Кто-нибудь в курсе, бэкпортами кто-нибудь уже занимается? На 2.4? :-)
> рассылка backports@altlinux.org.ua

http://lists.osdn.org.ua/wws/info/backports/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/