[devel] SharedLibsPolicy или хорошо что мы не Debian

[devel] SharedLibsPolicy или хорошо что мы не Debian

[Valery V. Inozemtsev]

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

Доброе утро, коллеги.

как говорится утро вечера мудренее... по мотивам #22272 родилась у меня
такая сказочка, назовем ее "Фиговый листочек SharedLibsPolicy, или слава
богу что мы не Debian". а теперь доказательство в примерах.

Пример 1:
libbluez/libbluez3, хотя здесь лучше сказать
libbluetooth.so.2/libbluetooth.so.3, что бы не было путаницы. если
рассматривать эту библиотеку как библиотеку, то все замечательно,
зависимости удовлетворены, пакеты пересборку проходят. но вот оказия,
отдельно эта библиотека совершенно бесполезна, т.е. нужно еще что то для
управления всей подсистемой bluetooth и это что то bluetoothd из пакета
bluez-4.XX. почему не hcid из bluez-utils? потому что если ты не
"чёкнутый профессор", помимо {bluetooth,hci}d понадобится
gnome-bluetooth/blueman/kbluetooth, которые собраны с libbluetooth.so.3
и нужен им bluez-4.XX. пользователь ставит тот же gammu и долго
удивляется, почему же он не работает?

Пример 2:
libpolkit/libpolkit1. полиси соблюдены, пожалуйста собирайте KDE4 с
polkit, gnome-2.28 с polkit1. но тут опять бяда - кто то из них будет
работать не так, как предполагалось. оказывается сам по себе polkit
работать не может, ему нужен ConsoleKit и рабочим будет тот polkit с
которым слинкован ConsoleKit

Пример 3:
libcdio
$ rpmquery -pl libcdio-0.81-alt2.i586.rpm | grep lib/lib
/usr/lib/libcdio.so.10
/usr/lib/libcdio.so.10.0.0
/usr/lib/libcdio_cdda.so.0
/usr/lib/libcdio_cdda.so.0.0.5
/usr/lib/libcdio_paranoia.so.0
/usr/lib/libcdio_paranoia.so.0.0.3
/usr/lib/libiso9660.so.7
/usr/lib/libiso9660.so.7.0.0
/usr/lib/libudf.so.0
/usr/lib/libudf.so.0.0.0
$ rpmquery -pl libcdio-0.82-alt1.i586.rpm | grep lib/lib
/usr/lib/libcdio.so.12
/usr/lib/libcdio.so.12.0.0
/usr/lib/libcdio_cdda.so.0
/usr/lib/libcdio_cdda.so.0.0.5
/usr/lib/libcdio_paranoia.so.0
/usr/lib/libcdio_paranoia.so.0.0.3
/usr/lib/libiso9660.so.7
/usr/lib/libiso9660.so.7.0.0
/usr/lib/libudf.so.0
/usr/lib/libudf.so.0.0.0
т.к. таск 15301 канул в лету, соблюдем полиси и обзовем их libcdio и
libcdio82 с provides/conflicts. gst-plugins-ugly я естественно соберу с
новой библиотекой. результат - установить одновременно, например,
openoffice.org и mpd невозможно

а теперь вопрос: так что же мы хотим, что бы пакеты собирались и имели
удовлетворенные зависимости, но при этом они либо оказываются не
рабочими, либо вместе не живут; или все же что бы можно было эти пакеты
установить не каждый по отдельности, а вместе, да при этом еще, о чудо,
они будут работать?

P.S. вспоминая зоопарк с libneonXX... была кучка пакетов собранная с
3-ми, 4-мя неонами, я потратил несколько часов на то что бы собрать их с
libneon последней версии.
сколько времени потребуется отдельно взятому мантейнеру на починку
одного пакета и стоит ли плодить четыре одинаковых библиотек с разным
soname?

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Anton Farygin]

13.11.2009 11:36, Valery V. Inozemtsev пишет:
> Доброе утро, коллеги.
>
> как говорится утро вечера мудренее... по мотивам #22272 родилась у меня
> такая сказочка, назовем ее "Фиговый листочек SharedLibsPolicy, или слава
> богу что мы не Debian". а теперь доказательство в примерах.
>

<поскипано>

Вообще, мне не совсем понятна идея плодить SharedLibs при наличии 
удобных инструментов для массовой пересборки пакетов.

Всё что нужно - это ACL на зависящие пакеты тому, кто собирает 
библиотеку с новым soname.

Но иногда, действительно есть необходимость плодить версии библиотек.

особенно тогда, когда клиентов пересобрать физически невозможно (бинари).

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Damir Shayhutdinov]

> Всё что нужно - это ACL на зависящие пакеты тому, кто собирает библиотеку с
> новым soname.
>
> Но иногда, действительно есть необходимость плодить версии библиотек.
>
> особенно тогда, когда клиентов пересобрать физически невозможно (бинари).

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

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Anton Farygin]

13.11.2009 14:14, Damir Shayhutdinov пишет:
>> Всё что нужно - это ACL на зависящие пакеты тому, кто собирает библиотеку с
>> новым soname.
>>
>> Но иногда, действительно есть необходимость плодить версии библиотек.
>>
>> особенно тогда, когда клиентов пересобрать физически невозможно (бинари).
>
> Это нужно в основном для облегчения дист-апгрейда, а также для
> возможности точечных апгрейдов.

Это некорректный подход, который может привести к неработоспособности 
системы в ряде случаев (примеры Валера привёл).

Как сделать правильно - давайте обсуждать.

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Led]

On Friday, 13 November 2009 13:17:50 Anton Farygin wrote:
> 13.11.2009 14:14, Damir Shayhutdinov пишет:
> >> Всё что нужно - это ACL на зависящие пакеты тому, кто собирает
> >> библиотеку с новым soname.
> >>
> >> Но иногда, действительно есть необходимость плодить версии библиотек.
> >>
> >> особенно тогда, когда клиентов пересобрать физически невозможно
> >> (бинари).
> >
> > Это нужно в основном для облегчения дист-апгрейда, а также для
> > возможности точечных апгрейдов.
>
> Это некорректный подход, который может привести к неработоспособности
> системы в ряде случаев (примеры Валера привёл).

И у меня есть реальные примеры, когда слепое следование SharedLibsPolicy 
приводит к упрятыванию проблемы от от мейнтейнера и проверки инкамингера на 
анметы, но приводит к трудноуловимым проблемам в рантайме.

> Как сделать правильно - давайте обсуждать.

Дык, не раз обсуждалось уже: "победили" ленивые приверженцы идею "главное 
чтобы в комнате было чистенько - пофиг, что под диваном гора мусора и оттуда 
сильно воняет".

-- 
Led

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Damir Shayhutdinov]

>>> Но иногда, действительно есть необходимость плодить версии библиотек.
>>>
>>> особенно тогда, когда клиентов пересобрать физически невозможно (бинари).
>>
>> Это нужно в основном для облегчения дист-апгрейда, а также для
>> возможности точечных апгрейдов.
>
> Это некорректный подход, который может привести к неработоспособности
> системы в ряде случаев (примеры Валера привёл).
>
> Как сделать правильно - давайте обсуждать.

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

Так что в примере 1 и в примере 2, совместная пересборка просто необходима.

А в примере 3, можно было libcdio.so.12 оставить в пакете libcdio12,
остальные сонеймы, которые не меняются, положить в пакет
libcdio12-extra или как там (в предположении что если сонейм не
поменяли, то совместимость осталась).

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Valery V. Inozemtsev]

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

> А в примере 3, можно было libcdio.so.12 оставить в пакете libcdio12,
> остальные сонеймы, которые не меняются, положить в пакет
> libcdio12-extra или как там (в предположении что если сонейм не
> поменяли, то совместимость осталась).

не выйдет. я не зря для примера взял именно libcdio. почему именно ее -
пусть это будет в качестве домашнего задания

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Damir Shayhutdinov]

>> А в примере 3, можно было libcdio.so.12 оставить в пакете libcdio12,
>> остальные сонеймы, которые не меняются, положить в пакет
>> libcdio12-extra или как там (в предположении что если сонейм не
>> поменяли, то совместимость осталась).
>
> не выйдет. я не зря для примера взял именно libcdio. почему именно ее -
> пусть это будет в качестве домашнего задания

Мне некогда включать телепата, да и неинтересно. Если у тебя нет
времени для разъяснения, значит не так уж и нужно обсуждение этого
всего. Пока по представленному rpm -qa | grep lib/lib не понятно, из
чего следует это самое домашнее задание.

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Anton Farygin]

13.11.2009 14:37, Damir Shayhutdinov пишет:
>>> А в примере 3, можно было libcdio.so.12 оставить в пакете libcdio12,
>>> остальные сонеймы, которые не меняются, положить в пакет
>>> libcdio12-extra или как там (в предположении что если сонейм не
>>> поменяли, то совместимость осталась).
>>
>> не выйдет. я не зря для примера взял именно libcdio. почему именно ее -
>> пусть это будет в качестве домашнего задания
>
> Мне некогда включать телепата, да и неинтересно. Если у тебя нет
> времени для разъяснения, значит не так уж и нужно обсуждение этого
> всего. Пока по представленному rpm -qa | grep lib/lib не понятно, из
> чего следует это самое домашнее задание.

+1

Валера, совершенно нет желания вникать в потроха всех библиотек. Неужто 
сложно объяснить ?

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Valery V. Inozemtsev]

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

В Птн, 13/11/2009 в 14:37 +0300, Damir Shayhutdinov пишет:
> >> А в примере 3, можно было libcdio.so.12 оставить в пакете libcdio12,
> >> остальные сонеймы, которые не меняются, положить в пакет
> >> libcdio12-extra или как там (в предположении что если сонейм не
> >> поменяли, то совместимость осталась).
> >
> > не выйдет. я не зря для примера взял именно libcdio. почему именно ее -
> > пусть это будет в качестве домашнего задания
> 
> Мне некогда включать телепата, да и неинтересно.

мне тоже

>  Если у тебя нет
> времени для разъяснения, значит не так уж и нужно обсуждение этого
> всего.

я и обсуждать? я не сторонник демократии (у нас это просто пустой
галдёшь), я сторонник тоталитаризма

>  Пока по представленному rpm -qa | grep lib/lib не понятно, из
> чего следует это самое домашнее задание.

из зависимостей между либами внутри пакета

-- 
Valery V. Inozemtsev

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Damir Shayhutdinov]

> я и обсуждать? я не сторонник демократии (у нас это просто пустой
> галдёшь), я сторонник тоталитаризма
И тоталитаризм, и демократия нуждаются в обсуждении... Не зря у нас
была страна Советов!

>>  Пока по представленному rpm -qa | grep lib/lib не понятно, из
>> чего следует это самое домашнее задание.
>
> из зависимостей между либами внутри пакета

А, то есть библиотеки с неизмененными сонеймами зависят от библиотеки
с измененным, а не наоборот?
Или что? Тогда и тут применим пункт о несмешении сонеймов в одном
адресном пространстве.

Что стоит обсудить - так это инструмент для обнаружения таких вот
затыков. Желательно в виде теста гирар-билдера, но можно и пост-тест
репокопа, если тест гирар-билдера будет невозможно сделать.

Для завтравки, если взять рекурсивный список NEEDED-зависимостей
любого бинарника (например, через ldd), отсеять дубликаты, после чего
от всех имен типа .so.N откусить все, что после .so (превратив
libcdio.so.10 в libcdio.so), то получившийся в результате список
должен содержать только уникальные имена.

То есть типа

ldd -r <бинарь> | grep -o '[A-Za-z0-9-]*\.so\.[a-z0-9.]*' -o | sort -u
| grep -o '[A-Za-z0-9-]*\.so'  | uniq -d
должно вернуть пустую строку.

Проверять это в принципе можно сразу после установки пакета в чрут.

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Денис Смирнов]

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

On Fri, Nov 13, 2009 at 01:42:07PM +0300, Anton Farygin wrote:

AF> Вообще, мне не совсем понятна идея плодить SharedLibs при наличии 
AF> удобных инструментов для массовой пересборки пакетов.

Объясняю популярно -- apt кривое убогое поделие, с нулевым интеллектом.
И чтобы создать пользователю видимость того что dist-upgrade между
дистрибутивами не является невозможным -- нужны всякие трюки.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Yury Aliaev]

13.11.2009 14:56, Денис Смирнов пишет:
>
> Объясняю популярно -- apt кривое убогое поделие, с нулевым интеллектом.
> И чтобы создать пользователю видимость того что dist-upgrade между
> дистрибутивами не является невозможным -- нужны всякие трюки.

Я не совсем понял вашу мысль. Вы хотели сказать "является возможным"? 
Зачем создавать видимость того, что dist-upgrade _НЕ_ является возможным?

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Денис Смирнов]

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

On Wed, Nov 18, 2009 at 10:17:21PM +0300, Yury Aliaev wrote:
>> Объясняю популярно -- apt кривое убогое поделие, с нулевым интеллектом.
>> И чтобы создать пользователю видимость того что dist-upgrade между
>> дистрибутивами не является невозможным -- нужны всякие трюки.
YA> Я не совсем понял вашу мысль. Вы хотели сказать "является возможным"? 
YA> Зачем создавать видимость того, что dist-upgrade _НЕ_ является возможным?

Я использовал конструкцию с двойным отрицанием -- "НЕ является
НЕвозможным" :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Yury Aliaev]

19.11.2009 05:40, Денис Смирнов пишет:
> On Wed, Nov 18, 2009 at 10:17:21PM +0300, Yury Aliaev wrote:
>>> Объясняю популярно -- apt кривое убогое поделие, с нулевым интеллектом.
>>> И чтобы создать пользователю видимость того что dist-upgrade между
>>> дистрибутивами не является невозможным -- нужны всякие трюки.
> YA>  Я не совсем понял вашу мысль. Вы хотели сказать "является возможным"?
> YA>  Зачем создавать видимость того, что dist-upgrade _НЕ_ является возможным?
>
> Я использовал конструкцию с двойным отрицанием -- "НЕ является
> НЕвозможным" :)

Да, пропустил при первом чтении, спасибо!

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Igor Vlasenko]

On Fri, Nov 13, 2009 at 01:42:07PM +0300, Anton Farygin wrote:
> Вообще, мне не совсем понятна идея плодить SharedLibs при наличии  
> удобных инструментов для массовой пересборки пакетов.
>
> Всё что нужно - это ACL на зависящие пакеты тому, кто собирает  
> библиотеку с новым soname.

Эти ACL еще попробуй получи :(

Кстати, Антон, не хотели бы добавить @qa в acl на часть 
своих пакетов? на вас repocop жалуется и патчи пишет.

Было бы хорошо, если бы у нас были механизмы 
автоматической выдачи nmu по факту Requires:

Что-то вроде 
$ ssh git.alt acl sisyphus foo nmu request-for-rebuild-with libbar.so
Accepted: foo depends on libbar.so.5 and you are the owner of libbar.so
girar-acl: 1 command(s) queued

Встроить бы такую проверку в girar-acl 
и выдавать NMU автоматически.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Anton Farygin]

13.11.2009 19:07, Igor Vlasenko пишет:
> On Fri, Nov 13, 2009 at 01:42:07PM +0300, Anton Farygin wrote:
>> Вообще, мне не совсем понятна идея плодить SharedLibs при наличии
>> удобных инструментов для массовой пересборки пакетов.
>>
>> Всё что нужно - это ACL на зависящие пакеты тому, кто собирает
>> библиотеку с новым soname.
>
> Эти ACL еще попробуй получи :(
>
> Кстати, Антон, не хотели бы добавить @qa в acl на часть
> своих пакетов? на вас repocop жалуется и патчи пишет.

Давно уже не видел патчи от repocop'а... на какие именно пакеты не 
хватает прав repocop'у, что бы внести изменения и где можно ознакомиться 
с этими патчами ?

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Igor Vlasenko]

On Fri, Nov 13, 2009 at 07:40:57PM +0300, Anton Farygin wrote:
>> Кстати, Антон, не хотели бы добавить @qa в acl на часть
>> своих пакетов? на вас repocop жалуется и патчи пишет.
>
> Давно уже не видел патчи от repocop'а... на какие именно пакеты не  
> хватает прав repocop'у, что бы внести изменения и где можно ознакомиться  
> с этими патчами ?

Имеющиеся патчи можно посмотреть
http://repocop.altlinux.org/pub/repocop/reports/diff/by-acl/rider/
"лидерские", на которые можно выдать @qa, в
http://repocop.altlinux.org/pub/repocop/reports/diff/by-leader/rider/

Но все переменчиво -- напишу новый тест и патчгенератор -
результат нечаянно нагрянет куда его совсем не ждешь.
Поэтом ухотел бы заранее просить добавить qa@ побОЛЬШЕ, ПОБОЛЬШЕ.

Все текущие сообщения от repocop -
http://repocop.altlinux.org/pub/repocop/reports/txt/by-acl/rider.txt
(первая колонка - packager; надо будет заменить на leader)

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Anton Farygin]

13.11.2009 20:12, Igor Vlasenko пишет:
> On Fri, Nov 13, 2009 at 07:40:57PM +0300, Anton Farygin wrote:
>>> Кстати, Антон, не хотели бы добавить @qa в acl на часть
>>> своих пакетов? на вас repocop жалуется и патчи пишет.
>>
>> Давно уже не видел патчи от repocop'а... на какие именно пакеты не
>> хватает прав repocop'у, что бы внести изменения и где можно ознакомиться
>> с этими патчами ?
>
> Имеющиеся патчи можно посмотреть
> http://repocop.altlinux.org/pub/repocop/reports/diff/by-acl/rider/
> "лидерские", на которые можно выдать @qa, в
> http://repocop.altlinux.org/pub/repocop/reports/diff/by-leader/rider/

Ага, готово. Не забывайте присылать ссылки на git, с которым можно 
мержиться.

Вообще, я патчи привык смотреть на www.sisyphus.ru, видимо оно глючное.

>
> Но все переменчиво -- напишу новый тест и патчгенератор -
> результат нечаянно нагрянет куда его совсем не ждешь.
> Поэтом ухотел бы заранее просить добавить qa@ побОЛЬШЕ, ПОБОЛЬШЕ.

qa@ - и не мечтайте. Вот @everybody - другое дело.

>
> Все текущие сообщения от repocop -
> http://repocop.altlinux.org/pub/repocop/reports/txt/by-acl/rider.txt
> (первая колонка - packager; надо будет заменить на leader)

Да, на Leader - это правильно.

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Yury Aliaev]

13.11.2009 19:07, Igor Vlasenko пишет:

>
> Было бы хорошо, если бы у нас были механизмы
> автоматической выдачи nmu по факту Requires:
>
> Что-то вроде
> $ ssh git.alt acl sisyphus foo nmu request-for-rebuild-with libbar.so
> Accepted: foo depends on libbar.so.5 and you are the owner of libbar.so
> girar-acl: 1 command(s) queued
>
> Встроить бы такую проверку в girar-acl
> и выдавать NMU автоматически.
>

Я подобное уже предлагал, наверное, с год тому назад, правда, не в столь 
формализованной форме. Сейчас, похоже, кто-то опять наступил на эти же 
грабли, и обсуждение пошло по очередному кругу. Да только грабли всё 
лежат и лежат...

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 1337 bytes --]

On Friday 13 November 2009, Valery V. Inozemtsev wrote:

[...]
>  libcdio и libcdio82 с provides/conflicts. gst-plugins-ugly я
>  естественно соберу с новой библиотекой. результат - установить
>  одновременно, например, openoffice.org и mpd невозможно
Исправить эти самые provides/conflicts, значит, нужно.
Просто, мантейнер заранее должен стараться предусмотреть, чтоб после 
исправления не было проблем с обновлением.

> а теперь вопрос: так что же мы хотим, что бы пакеты собирались и
>  имели удовлетворенные зависимости, но при этом они либо
>  оказываются не рабочими, либо вместе не живут; или все же что бы
>  можно было эти пакеты установить не каждый по отдельности, а
>  вместе, да при этом еще, о чудо, они будут работать?
Например, нужно, чтоб libname-devel был всегда тот, с которым нужно 
собирать по умолчанию.
Например, необходимость сборки с libsensors3-devel мне донесли 
лично. У меня в BuildRequires стояло libsensors-devel. Это означает, 
что рано или поздно у меня опять перестанет собираться с правильной 
библиотекой, несмотря на то, что проблем со сборкой никаких не 
будет.

Проблема, лишь, описать в policy, какую из версий называть libname-
devel и sisyphus_check такой придумать.

[...]

-- 
Regards, Sergey, ALT Linux, http://www.altlinux.ru/
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] SharedLibsPolicy

[Michael Shigorin]

On Fri, Nov 13, 2009 at 11:36:32AM +0300, Valery V. Inozemtsev wrote:
> как говорится утро вечера мудренее... по мотивам #22272

...намудрил, да.

> Пример 1:
> libbluez/libbluez3, хотя здесь лучше сказать
> libbluetooth.so.2/libbluetooth.so.3, что бы не было путаницы.
> если рассматривать эту библиотеку как библиотеку, то все
> замечательно, зависимости удовлетворены, пакеты пересборку
> проходят. но вот оказия, отдельно эта библиотека совершенно
> бесполезна, т.е. нужно еще что то для управления всей
> подсистемой bluetooth и это что то bluetoothd из пакета
> bluez-4.XX. почему не hcid из bluez-utils? потому что если ты
> не "чёкнутый профессор", помимо {bluetooth,hci}d понадобится
> gnome-bluetooth/blueman/kbluetooth, которые собраны с
> libbluetooth.so.3 и нужен им bluez-4.XX. пользователь ставит
> тот же gammu и долго удивляется, почему же он не работает?

Спасибо тебе за эпитет, а только "пользователь" для тебя уже
как вот здесь описано: http://lwn.net/Articles/357366/?
Мне эти блюеманы не сдались трижды.  kdebluetooth (третий)
раз в пятилетку применяю при спаривании, после переезда на
dbus не получается пользоваться нормальным PIN-скриптом.

Так вот посмотри, что ты заявляешь: полиси, которое и не
претендует на решение всех мировых проблем с разделяемыми
библиотеками -- отбрасываешь на основании ряда узких частных
случаев, где вообще-то уместен ещё и мозг майнтейнера.
Несмотря на то, что для гораздо более типичных случаев это
полиси либо ничем не вредит, либо тупо выручает как майнтейнеров
связанных по зависимостям на какую-либо библиотеку пакетов,
так и пользователей, которым переживать такие переезды и хорошо
бы без ставшего многим привычным порыва апта снести полсистемы.

(да, и gammu у меня *работает*, что от него и требуется)

> Пример 2:
> libpolkit/libpolkit1. полиси соблюдены, пожалуйста собирайте KDE4 с
> polkit, gnome-2.28 с polkit1. но тут опять бяда - кто то из них будет
> работать не так, как предполагалось. оказывается сам по себе polkit
> работать не может, ему нужен ConsoleKit и рабочим будет тот polkit с
> которым слинкован ConsoleKit

Возможно ли это выразить в терминах Conflicts:?

> Пример 3:
[...]
> т.к. таск 15301 канул в лету, соблюдем полиси и обзовем их
> libcdio и libcdio82 с provides/conflicts. gst-plugins-ugly я
> естественно соберу с новой библиотекой. результат - установить
> одновременно, например, openoffice.org и mpd невозможно

И чем была бы лучше ситуация при отсутствии как SharedLibsPolicy,
так и возможности оперативно всех как минимум пересобрать,
а порой ещё и пропатчить?

Вот возьми листик бумаги, подели на плюсы-минусы и опиши своё
предложение (которого я не наблюдаю) против SLP.

> а теперь вопрос: так что же мы хотим, что бы пакеты собирались
> и имели удовлетворенные зависимости, но при этом они либо
> оказываются не рабочими, либо вместе не живут; или все же что
> бы можно было эти пакеты установить не каждый по отдельности, а
> вместе, да при этом еще, о чудо, они будут работать?

Полиси может помось с "собирались и имели", а со всем остальным
задача _остаётся_ на майнтейнере.

Или предлагается молоток выкинуть и гвозди руками забивать?
Ну так молоток и не решает вопроса, куда бить и какой длиной.

> P.S. вспоминая зоопарк с libneonXX... была кучка пакетов
> собранная с 3-ми, 4-мя неонами, я потратил несколько часов на
> то что бы собрать их с libneon последней версии.  сколько
> времени потребуется отдельно взятому мантейнеру на починку
> одного пакета и стоит ли плодить четыре одинаковых библиотек с
> разным soname?

Ну да, ну да.  Это время делится на въезд в проблему и N кусочков
исправления конкретных ситуаций.  Баланс может быть сильно
разным, нередко въезд намного дороже конкретного исправления
(и одному человеку разобраться и починить пачку пакетов намного
быстрее, чем N человекам N раз разобраться и починить по пакету).

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

PS: помимо дебиана, lib%name%soname давно используется как
минимум в mandriva и opensuse, и чуточку -- даже в федоре.

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

Re: [devel] SharedLibsPolicy

[Led]

On Friday, 13 November 2009 23:25:26 Michael Shigorin wrote:
> On Fri, Nov 13, 2009 at 11:36:32AM +0300, Valery V. Inozemtsev wrote:
> > как говорится утро вечера мудренее... по мотивам #22272
>
> ...намудрил, да.
>
> > Пример 1:
> > libbluez/libbluez3, хотя здесь лучше сказать
> > libbluetooth.so.2/libbluetooth.so.3, что бы не было путаницы.
> > если рассматривать эту библиотеку как библиотеку, то все
> > замечательно, зависимости удовлетворены, пакеты пересборку
> > проходят. но вот оказия, отдельно эта библиотека совершенно
> > бесполезна, т.е. нужно еще что то для управления всей
> > подсистемой bluetooth и это что то bluetoothd из пакета
> > bluez-4.XX. почему не hcid из bluez-utils? потому что если ты
> > не "чёкнутый профессор", помимо {bluetooth,hci}d понадобится
> > gnome-bluetooth/blueman/kbluetooth, которые собраны с
> > libbluetooth.so.3 и нужен им bluez-4.XX. пользователь ставит
> > тот же gammu и долго удивляется, почему же он не работает?
>
> Спасибо тебе за эпитет, а только "пользователь" для тебя уже
> как вот здесь описано: http://lwn.net/Articles/357366/?
> Мне эти блюеманы не сдались трижды.  kdebluetooth (третий)
> раз в пятилетку применяю при спаривании, после переезда на
> dbus не получается пользоваться нормальным PIN-скриптом.
>
> Так вот посмотри, что ты заявляешь: полиси, которое и не
> претендует на решение всех мировых проблем с разделяемыми
> библиотеками -- отбрасываешь на основании ряда узких частных
> случаев, где вообще-то уместен ещё и мозг майнтейнера.

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

> Несмотря на то, что для гораздо более типичных случаев это
> полиси либо ничем не вредит, либо тупо выручает как майнтейнеров
> связанных по зависимостям на какую-либо библиотеку пакетов,
> так и пользователей, которым переживать такие переезды и хорошо
> бы без ставшего многим привычным порыва апта снести полсистемы.
>
> (да, и gammu у меня *работает*, что от него и требуется)
>
> > Пример 2:
> > libpolkit/libpolkit1. полиси соблюдены, пожалуйста собирайте KDE4 с
> > polkit, gnome-2.28 с polkit1. но тут опять бяда - кто то из них будет
> > работать не так, как предполагалось. оказывается сам по себе polkit
> > работать не может, ему нужен ConsoleKit и рабочим будет тот polkit с
> > которым слинкован ConsoleKit
>
> Возможно ли это выразить в терминах Conflicts:?
>
> > Пример 3:
>
> [...]
>
> > т.к. таск 15301 канул в лету, соблюдем полиси и обзовем их
> > libcdio и libcdio82 с provides/conflicts. gst-plugins-ugly я
> > естественно соберу с новой библиотекой. результат - установить
> > одновременно, например, openoffice.org и mpd невозможно
>
> И чем была бы лучше ситуация при отсутствии как SharedLibsPolicy,
> так и возможности оперативно всех как минимум пересобрать,
> а порой ещё и пропатчить?

В начале этого полиси следует написать большимы жирными буквати "использовать 
только в крайнем случае, если другими методами задача не решается"

>
> Вот возьми листик бумаги, подели на плюсы-минусы и опиши своё
> предложение (которого я не наблюдаю) против SLP.

Тебе не кажется, что что-то рисовать, чтобы ко-му-то что-то доказать - это 
пустая трата времени (ИМХО)?

>
> > а теперь вопрос: так что же мы хотим, что бы пакеты собирались
> > и имели удовлетворенные зависимости, но при этом они либо
> > оказываются не рабочими, либо вместе не живут; или все же что
> > бы можно было эти пакеты установить не каждый по отдельности, а
> > вместе, да при этом еще, о чудо, они будут работать?
>
> Полиси может помось с "собирались и имели", а со всем остальным
> задача _остаётся_ на майнтейнере.

Мне не очень импонирует идея, чтобы пакеты "имели" пользователя.

>
> Или предлагается молоток выкинуть и гвозди руками забивать?
> Ну так молоток и не решает вопроса, куда бить и какой длиной.
>
> > P.S. вспоминая зоопарк с libneonXX... была кучка пакетов
> > собранная с 3-ми, 4-мя неонами, я потратил несколько часов на
> > то что бы собрать их с libneon последней версии.  сколько
> > времени потребуется отдельно взятому мантейнеру на починку
> > одного пакета и стоит ли плодить четыре одинаковых библиотек с
> > разным soname?
>
> Ну да, ну да.  Это время делится на въезд в проблему и N кусочков
> исправления конкретных ситуаций.  Баланс может быть сильно
> разным, нередко въезд намного дороже конкретного исправления
> (и одному человеку разобраться и починить пачку пакетов намного
> быстрее, чем N человекам N раз разобраться и починить по пакету).
>
> Что характерно, это уже высказывалось и некоторыми майнтейнерами
> было принято во внимание на практике -- они стараются помогать
> коллегам, делясь анализом типичных разломов.
>
> PS: помимо дебиана, lib%name%soname давно используется как
> минимум в mandriva и opensuse, и чуточку -- даже в федоре.



-- 
Led

Re: [devel] SharedLibsPolicy

[Michael Shigorin]

On Fri, Nov 13, 2009 at 11:39:49PM +0200, Led wrote:
> > Так вот посмотри, что ты заявляешь: полиси, которое и не
> > претендует на решение всех мировых проблем с разделяемыми
> > библиотеками -- отбрасываешь на основании ряда узких частных
> > случаев, где вообще-то уместен ещё и мозг майнтейнера.
> В текущем виде это полиси только упрятывает проблемы, в первую
> очередь - от мейнтейнера, вылазят эти проблемы - уже у
> пользователя. Только диагностировать их у пользователя
> практически нереально.

И что именно ты предлагаешь?  Чтоб были проблемы _и_
с зависимостями, _и_ в ряде случаев -- с функциональностью?

Я-то думал, что если майнтейнер не разгильдяй вроде меня,
то по крайней мере сам сперва и наступит на грабли.
Поскольку он есть и пользователь того, что напаковал.
Если у себя на системе диагностировать тоже нереально
(с помощью колег при нужде) -- то мы _уже_ приплыли.

То есть продолжаю в упор не видеть, как именно упрятывает
и что становится хуже.  Если можешь -- объясни терпеливо
именно для меня.

> > > соберу с новой библиотекой. результат - установить
> > > одновременно, например, openoffice.org и mpd невозможно
> > И чем была бы лучше ситуация при отсутствии как
> > SharedLibsPolicy, так и возможности оперативно всех как
> > минимум пересобрать, а порой ещё и пропатчить?
> В начале этого полиси следует написать большимы жирными буквати
> "использовать только в крайнем случае, если другими методами
> задача не решается"

Если ты подразумеваешь ту часть, которая про упаковку библиотек
с разными сонеймами, то она там не главная.  И её да, используют
ровно тогда, когда это оказывается менее лениво (а порог здесь
поднят и ACL-ками в том числе).

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

> > Вот возьми листик бумаги, подели на плюсы-минусы и опиши своё
> > предложение (которого я не наблюдаю) против SLP.
> Тебе не кажется, что что-то рисовать, чтобы ко-му-то что-то
> доказать - это пустая трата времени (ИМХО)?

Валере предложил доказать в первую очередь себе -- наличие
минусов от этого полиси, которых бы не было в его отсутствие.

Отвечая на твой вопрос -- зависит.  Бывает пустая, бывает и нет.

> > > а теперь вопрос: так что же мы хотим, что бы пакеты собирались
> > > и имели удовлетворенные зависимости, но при этом они либо
> > > оказываются не рабочими, либо вместе не живут; или все же что
> > > бы можно было эти пакеты установить не каждый по отдельности, а
> > > вместе, да при этом еще, о чудо, они будут работать?
> > Полиси может помось с "собирались и имели", а со всем остальным
> > задача _остаётся_ на майнтейнере.
> Мне не очень импонирует идея, чтобы пакеты "имели" пользователя.

А ты не передёргивай, специально же оставил фрагмент:
"чтобы пакеты собирались и имели удовлетворенные зависимости". :)

PS: да-я-читал-и-применял-а-ты?

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

Re: [devel] SharedLibsPolicy

[Led]

On Saturday, 14 November 2009 00:55:29 Michael Shigorin wrote:
> On Fri, Nov 13, 2009 at 11:39:49PM +0200, Led wrote:
> > > Так вот посмотри, что ты заявляешь: полиси, которое и не
> > > претендует на решение всех мировых проблем с разделяемыми
> > > библиотеками -- отбрасываешь на основании ряда узких частных
> > > случаев, где вообще-то уместен ещё и мозг майнтейнера.
> >
> > В текущем виде это полиси только упрятывает проблемы, в первую
> > очередь - от мейнтейнера, вылазят эти проблемы - уже у
> > пользователя. Только диагностировать их у пользователя
> > практически нереально.
>
> И что именно ты предлагаешь?  Чтоб были проблемы _и_
> с зависимостями, _и_ в ряде случаев -- с функциональностью?
>
> Я-то думал, что если майнтейнер не разгильдяй вроде меня,
> то по крайней мере сам сперва и наступит на грабли.
> Поскольку он есть и пользователь того, что напаковал.
> Если у себя на системе диагностировать тоже нереально
> (с помощью колег при нужде) -- то мы _уже_ приплыли.
>
> То есть продолжаю в упор не видеть, как именно упрятывает
> и что становится хуже.  Если можешь -- объясни терпеливо
> именно для меня.

Лично тебе я это объяснял "на пальцах" как минимум раза два. И возражений от 
тебя не было. Если ты этого не помнишь - ну... я тебе в чём-то завидую:)

>
> > > > соберу с новой библиотекой. результат - установить
> > > > одновременно, например, openoffice.org и mpd невозможно
> > >
> > > И чем была бы лучше ситуация при отсутствии как
> > > SharedLibsPolicy, так и возможности оперативно всех как
> > > минимум пересобрать, а порой ещё и пропатчить?
> >
> > В начале этого полиси следует написать большимы жирными буквати
> > "использовать только в крайнем случае, если другими методами
> > задача не решается"
>
> Если ты подразумеваешь ту часть, которая про упаковку библиотек
> с разными сонеймами, то она там не главная.  И её да, используют
> ровно тогда, когда это оказывается менее лениво (а порог здесь
> поднят и ACL-ками в том числе).
>
> Ну допиши, это же вики.  Только перечитай сперва, чтоб в начале
> того, к чему это утверждение на самом деле относится.

Оно относится ко всему полиси, которое как раз и описывает порядок "упаковки 
библиотек с разными сонеймами". Но там ничего не говорится, чем грозит 
наличие библиотек с разными сонеймами в одном ползовательском репозитарии и, 
тем более, в одном сборочном репозитарии.

>
> > > Вот возьми листик бумаги, подели на плюсы-минусы и опиши своё
> > > предложение (которого я не наблюдаю) против SLP.
> >
> > Тебе не кажется, что что-то рисовать, чтобы ко-му-то что-то
> > доказать - это пустая трата времени (ИМХО)?
>
> Валере предложил доказать в первую очередь себе -- наличие
> минусов от этого полиси, которых бы не было в его отсутствие.
>
> Отвечая на твой вопрос -- зависит.  Бывает пустая, бывает и нет.

А бывает, что от личного мнения зависит. Ты высказал своё - я его уважаю. Вот 
только бывают ещё и не твои мнения, и среди них, как ни странно, попадаются 
тоже не неправильные:)

>
> > > > а теперь вопрос: так что же мы хотим, что бы пакеты собирались
> > > > и имели удовлетворенные зависимости, но при этом они либо
> > > > оказываются не рабочими, либо вместе не живут; или все же что
> > > > бы можно было эти пакеты установить не каждый по отдельности, а
> > > > вместе, да при этом еще, о чудо, они будут работать?
> > >
> > > Полиси может помось с "собирались и имели", а со всем остальным
> > > задача _остаётся_ на майнтейнере.
> >
> > Мне не очень импонирует идея, чтобы пакеты "имели" пользователя.
>
> А ты не передёргивай, специально же оставил фрагмент:
> "чтобы пакеты собирались и имели удовлетворенные зависимости". :)
>
> PS: да-я-читал-и-применял-а-ты?

Да. AFAIK чаще, чем ты. И сделал для себя вывод, что это нерационально и в 
конечном итоге - попытки "обмануть судьбу" с помощью безоглядного применения 
этого полиси приводят к непроизводительной пустой трате времени там, где его 
лучше потратить на решение проблемы, а не на её откладывание "на потом" 
(вдруг само рассосётся или кто-то другой решит).

-- 
Led

Re: [devel] SharedLibsPolicy

[Michael Shigorin]

On Sat, Nov 14, 2009 at 01:17:29AM +0200, Led wrote:
> > То есть продолжаю в упор не видеть, как именно упрятывает
> > и что становится хуже.  Если можешь -- объясни терпеливо
> > именно для меня.
> Лично тебе я это объяснял "на пальцах" как минимум раза два.
> И возражений от тебя не было.

А можешь здесь, для меня и архиву?

> Если ты этого не помнишь - ну...  я тебе в чём-то завидую:)

Да, есть такое.

> > Ну допиши, это же вики.  Только перечитай сперва, чтоб в
> > начале того, к чему это утверждение на самом деле относится.
> Оно относится ко всему полиси, которое как раз и описывает
> порядок "упаковки библиотек с разными сонеймами". Но там ничего
> не говорится, чем грозит наличие библиотек с разными сонеймами
> в одном ползовательском репозитарии

Чем грозит их отсутствие -- знаю, и IMCO это хуже на деле.

> и, тем более, в одном сборочном репозитарии.

Тут-то чем? (если -devel либо от последней, либо как qt3/qt4
-- всё равно разные _библиотеки_)

> > PS: да-я-читал-и-применял-а-ты?
> Да. AFAIK чаще, чем ты. И сделал для себя вывод, что это
> нерационально

Разумеется, дублирование версий в итоге нерационально.
Вопрос в том, чего ищешь: отточенного рационализма или
чтоб живым людям толк был от сделанного.  Не всегда
получается сочетать, порой именно "или" стоит.

> и в конечном итоге - попытки "обмануть судьбу" с помощью
> безоглядного применения этого полиси

Безоглядно применять вообще ничего не стоит.

> приводят к непроизводительной пустой трате времени там, где его
> лучше потратить на решение проблемы, а не на её откладывание
> "на потом" (вдруг само рассосётся или кто-то другой решит).

А эта проблема во многом упирается в сборочную инфраструктуру
(собсно viy@ в письмах рядом и предлагает возможные решения).

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

Re: [devel] SharedLibsPolicy

[Денис Смирнов]

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

On Fri, Nov 13, 2009 at 11:39:49PM +0200, Led wrote:

L> В текущем виде это полиси только упрятывает проблемы, в первую очередь - от 
L> мейнтейнера, вылазят эти проблемы - уже у пользователя. Только 
L> диагностировать их у пользователя практически нереально.

Это полиси предназначено для решения другой проблемы -- проблема
называется "apt-get -- тупое глючное поделие".

L> В начале этого полиси следует написать большимы жирными буквати "использовать 
L> только в крайнем случае, если другими методами задача не решается"

Нет, не так. Ситуаций где оно полезно куда больше чем где вредно. Причем
там где вредно, нужно просто применить дополнительные костыли, чтобы
решить все проблемы.

Повторюсь, такие системообращующие пакеты как libdb, например, уже многие
годы следуют этому полиси. Без всяких проблем.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy

[Led]

On Saturday, 14 November 2009 22:25:31 Денис Смирнов wrote:
> On Fri, Nov 13, 2009 at 11:39:49PM +0200, Led wrote:
>
> L> В текущем виде это полиси только упрятывает проблемы, в первую очередь -
> от L> мейнтейнера, вылазят эти проблемы - уже у пользователя. Только
> L> диагностировать их у пользователя практически нереально.
>
> Это полиси предназначено для решения другой проблемы -- проблема
> называется "apt-get -- тупое глючное поделие".

apt-get здесь ни при чём.

>
> L> В начале этого полиси следует написать большимы жирными буквати
> "использовать L> только в крайнем случае, если другими методами задача не
> решается"
>
> Нет, не так. Ситуаций где оно полезно куда больше чем где вредно. Причем
> там где вредно, нужно просто применить дополнительные костыли, чтобы
> решить все проблемы.
>
> Повторюсь, такие системообращующие пакеты как libdb, например, уже многие
> годы следуют этому полиси. Без всяких проблем.

От того, что вы проблем не видите, не значит, что их нет. Это только 
доказывает, что они очень глубоко спрятаны (в т.ч. и благодаря 
SharedLibsPolicy)

-- 
Led

Re: [devel] SharedLibsPolicy

[Денис Смирнов]

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

On Sat, Nov 14, 2009 at 10:45:10PM +0200, Led wrote:

L> apt-get здесь ни при чём.

Это ты так думаешь, что не причем. apt при смене soname внутри пакета и
dist-upgrade ведет себя неадекватно. Вплоть до сноса всех зависимых
пакетов, вместо обновления.

L> От того, что вы проблем не видите, не значит, что их нет. Это только 
L> доказывает, что они очень глубоко спрятаны (в т.ч. и благодаря 
L> SharedLibsPolicy)

Повторюсь -- в нашем репозитории эти проблемы редкие.

Единственная ситуация которая может привести к реально проблемам (т.е.
непредсказуемому поведению ПО), это когда приложение A требует библиотеки
B и C, а библиотека B требует также библиотеку C но другой версии.

Это -- действительно потенциальная грабля.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy

[Led]

On Sunday, 15 November 2009 00:20:00 Денис Смирнов wrote:
> On Sat, Nov 14, 2009 at 10:45:10PM +0200, Led wrote:
>
> L> apt-get здесь ни при чём.
>
> Это ты так думаешь, что не причем. apt при смене soname внутри пакета и
> dist-upgrade ведет себя неадекватно. Вплоть до сноса всех зависимых
> пакетов, вместо обновления.

Вы уверены, что знаете точную причину такого поведения? Вы уверены, что это 
бага/фича apt'а, а не проблема кривой упаковки пакета?

>
> L> От того, что вы проблем не видите, не значит, что их нет. Это только
> L> доказывает, что они очень глубоко спрятаны (в т.ч. и благодаря
> L> SharedLibsPolicy)
>
> Повторюсь -- в нашем репозитории эти проблемы редкие.
>
> Единственная ситуация которая может привести к реально проблемам (т.е.
> непредсказуемому поведению ПО), это когда приложение A требует библиотеки
> B и C, а библиотека B требует также библиотеку C но другой версии.
>
> Это -- действительно потенциальная грабля.

Этого недостаточно? Есть способы предугадать её? Есть способы её диагностики в 
рабочей системе?

Почему вы считаете, что эта "грабля" потенциальная? Она вполне реальная, в 
Sisyphus встречалась. Сколько раз она там была - неизвестно, потому в тех 
нескольких случаях когда была замечена - это происходило случайно.

-- 
Led

Re: [devel] SharedLibsPolicy

[Денис Смирнов]

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

On Sun, Nov 15, 2009 at 12:30:55AM +0200, Led wrote:

L> Вы уверены, что знаете точную причину такого поведения? Вы уверены, что это 
L> бага/фича apt'а, а не проблема кривой упаковки пакета?

Я точно знаю что эта проблема стабильно воспроизводится при использовании
compat-пакетов.

А без использования compat-пакетов также стабильно ломаются полностью
точечные обновления.

>> Это -- действительно потенциальная грабля.
L> Этого недостаточно? Есть способы предугадать её? Есть способы её диагностики в 
L> рабочей системе?
L> Почему вы считаете, что эта "грабля" потенциальная? Она вполне реальная, в 
L> Sisyphus встречалась. Сколько раз она там была - неизвестно, потому в тех 
L> нескольких случаях когда была замечена - это происходило случайно.

Диагностировать автоматически подобную граблю возможно, хотя это и требует
усилий. Поэтому борьбу я бы предпочел сконцентрировать в этой области. а
не отказываться от SharedLibsPolicy (такой отказ является лечение головной
боли гильотиной).

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy

[Led]

On Sunday, 15 November 2009 00:55:45 Денис Смирнов wrote:
> On Sun, Nov 15, 2009 at 12:30:55AM +0200, Led wrote:
>
> L> Вы уверены, что знаете точную причину такого поведения? Вы уверены, что
> это L> бага/фича apt'а, а не проблема кривой упаковки пакета?
>
> Я точно знаю что эта проблема стабильно воспроизводится при использовании
> compat-пакетов.
>
> А без использования compat-пакетов также стабильно ломаются полностью
> точечные обновления.
>
> >> Это -- действительно потенциальная грабля.
>
> L> Этого недостаточно? Есть способы предугадать её? Есть способы её
> диагностики в L> рабочей системе?
> L> Почему вы считаете, что эта "грабля" потенциальная? Она вполне реальная,
> в L> Sisyphus встречалась. Сколько раз она там была - неизвестно, потому в
> тех L> нескольких случаях когда была замечена - это происходило случайно.
>
> Диагностировать автоматически подобную граблю возможно, хотя это и требует
> усилий. Поэтому борьбу я бы предпочел сконцентрировать в этой области. а
> не отказываться от SharedLibsPolicy (такой отказ является лечение головной
> боли гильотиной).

Вы же предлагаете "лечить" болезнь только обезбаливающим, по принципу "сейчас 
не болит? значит вылечили!"

-- 
Led

Re: [devel] SharedLibsPolicy

[Денис Смирнов]

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

On Sun, Nov 15, 2009 at 01:19:55AM +0200, Led wrote:

L> Вы же предлагаете "лечить" болезнь только обезбаливающим, по принципу "сейчас 
L> не болит? значит вылечили!"

Нет, я предлагаю лечить совершенно другую болезнь.

По поводу той грабли, о которой мы говорим -- наличие приложения которое
бы тестировало систему на предмет таких граблей тебя устроит?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy

[Led]

On Sunday, 15 November 2009 02:46:55 Денис Смирнов wrote:
> On Sun, Nov 15, 2009 at 01:19:55AM +0200, Led wrote:
>
> L> Вы же предлагаете "лечить" болезнь только обезбаливающим, по принципу
> "сейчас L> не болит? значит вылечили!"
>
> Нет, я предлагаю лечить совершенно другую болезнь.

Какую?

>
> По поводу той грабли, о которой мы говорим -- наличие приложения которое
> бы тестировало систему на предмет таких граблей тебя устроит?

Устроило наличие в икаминге "приложения", которое бы гарантированно не пускало 
в репозитарий пакеты, могущие привести к таким "граблям".

-- 
Led

Re: [devel] SharedLibsPolicy

[Денис Смирнов]

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

On Sun, Nov 15, 2009 at 03:36:12AM +0200, Led wrote:
>> Нет, я предлагаю лечить совершенно другую болезнь.
L> Какую?

В тупом apt не работает dist-upgrade.

L> Устроило наличие в икаминге "приложения", которое бы гарантированно не пускало 
L> в репозитарий пакеты, могущие привести к таким "граблям".

Предлагаемые методы неисполнения SharedLibsPolicy гарантировано ломают
обновления, также гарантировано ломают точечные обновления, и при этом
_иногда_ решают поднятую проблему.

Иногда, потому что ряд критичных пакетов (вроде libdb) могут
присутствовать в репозитории несколькими версиями одновременно.

Но написать такое приложение -- да, было бы полезно. Не хочешь взяться за
это? :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------


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

Re: [devel] SharedLibsPolicy

[Led]

On Sunday, 15 November 2009 09:06:52 Денис Смирнов wrote:
> On Sun, Nov 15, 2009 at 03:36:12AM +0200, Led wrote:
> >> Нет, я предлагаю лечить совершенно другую болезнь.
>
> L> Какую?
>
> В тупом apt не работает dist-upgrade.

Почему ищем ключи не там, где потеряли, а там, где проще - под фонарём?

>
> L> Устроило наличие в икаминге "приложения", которое бы гарантированно не
> пускало L> в репозитарий пакеты, могущие привести к таким "граблям".
>
> Предлагаемые методы неисполнения SharedLibsPolicy

Какие?

> гарантировано ломают 
> обновления, также гарантировано ломают точечные обновления, и при этом
> _иногда_ решают поднятую проблему.

"Точечные обновления" могут "гарантированно ломаються" даже со всеми 
предлагаемыми костылями и зоопарком libfooN (где N - разные циферки). Пример:

app собран с libfoo.so.1.0, соответственно слинкован с libfoo.so.1 и имеет 
зависимость на  libfoo.so.1

далее, появляется libfoo.so.1.1 (полностью обратно совместимая с 
libfoo.so.1.0).

далее, появляется новый app, собран с libfoo.so.1.1, соответственно слинкован 
с libfoo.so.1 и имеет зависимость на  libfoo.so.1

далее появляетесь вы, делаете "точечное обновление" app - всё отлично 
обновляется.

запускаете app - упс! "неизвестный символ". app "упало" :(

SharedLibsPolicy в таком случае - никак не помогает :(

>
> Иногда, потому что ряд критичных пакетов (вроде libdb) могут
> присутствовать в репозитории несколькими версиями одновременно.

ls -1 /lib64/libdb*
/lib64/libdb-4.4.so
/lib64/libdb-4.5.so
/lib64/libdb-4.7.so

Неудачный пример. Формально это разные библиотеки, с разными именами, без 
версии после "so"

>
> Но написать такое приложение -- да, было бы полезно. Не хочешь взяться за
> это? :)

А смысл? Следить за бардаком? ИМХО нужно просто не устраивать бардак.

-- 
Led

Re: [devel] SharedLibsPolicy

[Michael Shigorin]

On Sun, Nov 15, 2009 at 10:00:02PM +0200, Led wrote:
> запускаете app - упс! "неизвестный символ". app "упало" :(
> SharedLibsPolicy в таком случае - никак не помогает :(

Но и не мешает -- всё равно в таком случае придётся догадаться
обновить точно тот же libfoo.

> > Но написать такое приложение -- да, было бы полезно. Не
> > хочешь взяться за это? :)
> А смысл? Следить за бардаком? ИМХО нужно просто не устраивать
> бардак.

<jt>
Правильно, и давай начнём с увольнения дворников и упразднения
garbage collector'ов.  Пусть все не мусорят, аккуратно обходятся
с памятью, дельфины не выбрасываются, а Microsoft не врёт.
</jt>

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

Re: [devel] SharedLibsPolicy

[Led]

On Sunday, 15 November 2009 22:27:38 Michael Shigorin wrote:
> On Sun, Nov 15, 2009 at 10:00:02PM +0200, Led wrote:
> > запускаете app - упс! "неизвестный символ". app "упало" :(
> > SharedLibsPolicy в таком случае - никак не помогает :(
>
> Но и не мешает -- всё равно в таком случае придётся догадаться
> обновить точно тот же libfoo.

Да, не помогает и не мешает. Поэтому мне и не понятно, почему вы 
привели "точечные обновления" в качестве аргумента в пользу SharedLibsPolicy.

>
> > > Но написать такое приложение -- да, было бы полезно. Не
> > > хочешь взяться за это? :)
> >
> > А смысл? Следить за бардаком? ИМХО нужно просто не устраивать
> > бардак.
>
> <jt>
> Правильно, и давай начнём с увольнения дворников и упразднения
> garbage collector'ов.  Пусть все не мусорят, аккуратно обходятся
> с памятью, дельфины не выбрасываются, а Microsoft не врёт.
> </jt>

Дворники (мейнтейнеры) лолжны всего лишь делать ту работу, за которую они 
добровольно взялись: собирать, чинить, обновлять пакеты (в т.ч. и пакеты 
lib*), а не пытаться улинивать от работы пользуясь всякими панацеями (в 
данном случае - SharedLibsPolicy).

Про дельфинов - смешно:)
Про память: вы и с мемори-ликами тоже предложите бороться не исправлением 
кода, а принятием и навязыванием какой-нибудь MemoryLeakPolicy?:)

-- 
Led

Re: [devel] SharedLibsPolicy

[Michael Shigorin]

On Sun, Nov 15, 2009 at 11:01:30PM +0200, Led wrote:
> > > запускаете app - упс! "неизвестный символ". app "упало" :(
> > > SharedLibsPolicy в таком случае - никак не помогает :(
> > Но и не мешает -- всё равно в таком случае придётся
> > догадаться обновить точно тот же libfoo.
> Да, не помогает и не мешает. Поэтому мне и не понятно, почему
> вы привели "точечные обновления" в качестве аргумента в пользу
> SharedLibsPolicy.

Вы с Валерой упёрлись в точечные случаи и мотивируете тем,
что в них не помогает -- нежелание воспринимать инструмент,
который помогает или по крайней мере не ухудшает ситуацию
в большинстве случаев.

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

> Дворники (мейнтейнеры) лолжны всего лишь делать ту работу, за
> которую они добровольно взялись: собирать, чинить, обновлять
> пакеты (в т.ч. и пакеты lib*), а не пытаться улинивать от
> работы пользуясь всякими панацеями (в данном случае -
> SharedLibsPolicy).

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

> Про память: вы и с мемори-ликами тоже предложите бороться не
> исправлением кода, а принятием и навязыванием какой-нибудь
> MemoryLeakPolicy?:)

Да кто тебе навязывает-то?  SharedLibsPolicy, кажется,
ничем даже не контролируется.

Если мемлики будут возникать не в "одном понятном месте",
а в потрохах штуковины с кучей взаимодействий -- то для
_возможности_ людям выяснить, кто кого куда утёк, при
невозможности в разумное время охватить весь код может
помочь и полиси по стратегии загоняния тигра в нужную
половину пустыни.  Впрочем, здесь совсем чайник. :)

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

Re: [devel] SharedLibsPolicy

[Anton Farygin]

16.11.2009 00:27, Michael Shigorin пишет:
> On Sun, Nov 15, 2009 at 11:01:30PM +0200, Led wrote:
>> Про память: вы и с мемори-ликами тоже предложите бороться не
>> исправлением кода, а принятием и навязыванием какой-нибудь
>> MemoryLeakPolicy?:)
>
> Да кто тебе навязывает-то?  SharedLibsPolicy, кажется,
> ничем даже не контролируется.

Начнём с того, что оно в общем-то, и не принято.

Т.е. - в данный момент это рекомендация, не более того.

[devel] symbols into dependencies

[Alexey Tourbin]

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

On Sun, Nov 15, 2009 at 10:00:02PM +0200, Led wrote:
> "Точечные обновления" могут "гарантированно ломаються" даже со всеми 
> предлагаемыми костылями и зоопарком libfooN (где N - разные циферки). Пример:
> 
> app собран с libfoo.so.1.0, соответственно слинкован с libfoo.so.1 и имеет 
> зависимость на  libfoo.so.1
> 
> далее, появляется libfoo.so.1.1 (полностью обратно совместимая с 
> libfoo.so.1.0).
> 
> далее, появляется новый app, собран с libfoo.so.1.1, соответственно слинкован 
> с libfoo.so.1 и имеет зависимость на  libfoo.so.1
> 
> далее появляетесь вы, делаете "точечное обновление" app - всё отлично 
> обновляется.
> 
> запускаете app - упс! "неизвестный символ". app "упало" :(
> 
> SharedLibsPolicy в таком случае - никак не помогает :(

Есть идея формировать зависимости на сонеймы с учетом символов.
Это может выглядеть так:

	%package -n libfoo
	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)

	%package -n foo
	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная строка)

То есть реализовать зависимости специального вида, которые представляют
собой "множество строк" (символов).  Вместо обычного сравнения версий
для таких зависимостей будет выполняться проверка, что requires set
является подмножеством provides set.

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

Re: [devel] symbols into dependencies

[Led]

On Sunday, 15 November 2009 23:14:43 Alexey Tourbin wrote:
> On Sun, Nov 15, 2009 at 10:00:02PM +0200, Led wrote:
> > "Точечные обновления" могут "гарантированно ломаються" даже со всеми
> > предлагаемыми костылями и зоопарком libfooN (где N - разные циферки).
> > Пример:
> >
> > app собран с libfoo.so.1.0, соответственно слинкован с libfoo.so.1 и
> > имеет зависимость на  libfoo.so.1
> >
> > далее, появляется libfoo.so.1.1 (полностью обратно совместимая с
> > libfoo.so.1.0).
> >
> > далее, появляется новый app, собран с libfoo.so.1.1, соответственно
> > слинкован с libfoo.so.1 и имеет зависимость на  libfoo.so.1
> >
> > далее появляетесь вы, делаете "точечное обновление" app - всё отлично
> > обновляется.
> >
> > запускаете app - упс! "неизвестный символ". app "упало" :(
> >
> > SharedLibsPolicy в таком случае - никак не помогает :(
>
> Есть идея формировать зависимости на сонеймы с учетом символов.
> Это может выглядеть так:
>
> 	%package -n libfoo
> 	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
>
> 	%package -n foo
> 	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная строка)
>
> То есть реализовать зависимости специального вида, которые представляют
> собой "множество строк" (символов).  Вместо обычного сравнения версий
> для таких зависимостей будет выполняться проверка, что requires set
> является подмножеством provides set.

А разве из существующих libfoo.so.1.1 и libfoo.so.1.2 не видно, что первая 
является подмножеством второй (из-за 1 < 2)? Зачем тогда ещё дополнительные 
хэши в зависимостях вводить?

Прошу прощения, если понял вашу идею неправильно или неполностью.

-- 
Led

Re: [devel] symbols into dependencies

[Alexey Tourbin]

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

On Mon, Nov 16, 2009 at 12:47:42AM +0200, Led wrote:
> On Sunday, 15 November 2009 23:14:43 Alexey Tourbin wrote:
> > > app собран с libfoo.so.1.0, соответственно слинкован с libfoo.so.1 и
> > > имеет зависимость на  libfoo.so.1
> > >
> > > далее, появляется libfoo.so.1.1 (полностью обратно совместимая с
> > > libfoo.so.1.0).
> > >
> > > далее, появляется новый app, собран с libfoo.so.1.1, соответственно
> > > слинкован с libfoo.so.1 и имеет зависимость на  libfoo.so.1
> > >
> > > далее появляетесь вы, делаете "точечное обновление" app - всё отлично
> > > обновляется.
> > >
> > > запускаете app - упс! "неизвестный символ". app "упало" :(
> > >
> > > SharedLibsPolicy в таком случае - никак не помогает :(
> >
> > Есть идея формировать зависимости на сонеймы с учетом символов.
> > Это может выглядеть так:
> >
> > 	%package -n libfoo
> > 	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
> >
> > 	%package -n foo
> > 	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная строка)
> >
> > То есть реализовать зависимости специального вида, которые представляют
> > собой "множество строк" (символов).  Вместо обычного сравнения версий
> > для таких зависимостей будет выполняться проверка, что requires set
> > является подмножеством provides set.
> 
> А разве из существующих libfoo.so.1.1 и libfoo.so.1.2 не видно, что первая 
> является подмножеством второй (из-за 1 < 2)? Зачем тогда ещё дополнительные 
> хэши в зависимостях вводить?

А как узнать в какой версии появился "неизвестный символ", в 1.1 или 1.2?
По идее для каждого символа нужно проставить зависимость на минимальную
версию, в которой этой символ появился (и потом выбрать максимальную
версию из всех).  Но у нас нету этой информации при сборке пакетов, где
когда какие символы появились.  А информация какие символы нужны всё-таки
есть, и (при нескольких "но" в районе ldd) это информация абсолютно
первичная и правдивая, straight from the horse's mouth.

Кроме того, схема с комплементарным хешем отслеживает и удаление символов
(а не только добавление новых символов).

> Прошу прощения, если понял вашу идею неправильно или неполностью.

Правильно поняли, по-видимому.

Надо как-то обеспечить бинарную совместимость (на уровне зависимостей).
Ясно что сейчас она по большому счёту никак не обеспечена, а затея
с нашенскими version scripts нужно признать в лучшем случае half
successful, а по гамбургскому счету она себя не оправдала.  Так что
видимо придётся решаться на крутые меры.

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

Re: [devel] symbols into dependencies

[Led]

On Monday, 16 November 2009 01:11:56 Alexey Tourbin wrote:
> > > Есть идея формировать зависимости на сонеймы с учетом символов.
> > > Это может выглядеть так:
> > >
> > > 	%package -n libfoo
> > > 	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
> > >
> > > 	%package -n foo
> > > 	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная
> > > строка)
> > >
> > > То есть реализовать зависимости специального вида, которые представляют
> > > собой "множество строк" (символов).  Вместо обычного сравнения версий
> > > для таких зависимостей будет выполняться проверка, что requires set
> > > является подмножеством provides set.
> >
> > А разве из существующих libfoo.so.1.1 и libfoo.so.1.2 не видно, что
> > первая является подмножеством второй (из-за 1 < 2)? Зачем тогда ещё
> > дополнительные хэши в зависимостях вводить?
>
> А как узнать в какой версии появился "неизвестный символ", в 1.1 или 1.2?
> По идее для каждого символа нужно проставить зависимость на минимальную
> версию, в которой этой символ появился (и потом выбрать максимальную
> версию из всех).  Но у нас нету этой информации при сборке пакетов, где
> когда какие символы появились.  А информация какие символы нужны всё-таки
> есть, и (при нескольких "но" в районе ldd) это информация абсолютно
> первичная и правдивая, straight from the horse's mouth.
>
> Кроме того, схема с комплементарным хешем отслеживает и удаление символов
> (а не только добавление новых символов).

Т.е. отслеживать зависимости "досимвольно"? Спасибо, теперь понятно.

>
> > Прошу прощения, если понял вашу идею неправильно или неполностью.
>
> Правильно поняли, по-видимому.
>
> Надо как-то обеспечить бинарную совместимость (на уровне зависимостей).
> Ясно что сейчас она по большому счёту никак не обеспечена, а затея
> с нашенскими version scripts нужно признать в лучшем случае half
> successful, а по гамбургскому счету она себя не оправдала.

К сожалению :(

> Так что 
> видимо придётся решаться на крутые меры.

Предполагается ли Requires проставляться на полный хэш символов библиотеки, с 
которой слинкован бинарник при сборке, или только на минимально необходимый и 
достаточный хэш по факту используемых символов из этой библиотеки?

-- 
Led

Re: [devel] symbols into dependencies

[Alexey Tourbin]

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

On Mon, Nov 16, 2009 at 01:43:52AM +0200, Led wrote:
> On Monday, 16 November 2009 01:11:56 Alexey Tourbin wrote:
> > > > Есть идея формировать зависимости на сонеймы с учетом символов.
> > > > Это может выглядеть так:
> > > >
> > > > 	%package -n libfoo
> > > > 	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
> > > >
> > > > 	%package -n foo
> > > > 	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная
> > > > строка)
> > > >
> > > > То есть реализовать зависимости специального вида, которые представляют
> > > > собой "множество строк" (символов).  Вместо обычного сравнения версий
> > > > для таких зависимостей будет выполняться проверка, что requires set
> > > > является подмножеством provides set.
> > >
> > > А разве из существующих libfoo.so.1.1 и libfoo.so.1.2 не видно, что
> > > первая является подмножеством второй (из-за 1 < 2)? Зачем тогда ещё
> > > дополнительные хэши в зависимостях вводить?
> >
> > А как узнать в какой версии появился "неизвестный символ", в 1.1 или 1.2?
> > По идее для каждого символа нужно проставить зависимость на минимальную
> > версию, в которой этой символ появился (и потом выбрать максимальную
> > версию из всех).  Но у нас нету этой информации при сборке пакетов, где
> > когда какие символы появились.  А информация какие символы нужны всё-таки
> > есть, и (при нескольких "но" в районе ldd) это информация абсолютно
> > первичная и правдивая, straight from the horse's mouth.
> >
> > Кроме того, схема с комплементарным хешем отслеживает и удаление символов
> > (а не только добавление новых символов).
> 
> Т.е. отслеживать зависимости "досимвольно"? Спасибо, теперь понятно.

Да, "концептуальная" модель именно такая -- отслеживать символы
внутри сонейма.

Provides: (libfoo.so.1;foo_sym1,foo_sym2,foo_sym3,...)
Requires: (libfoo.so.1;foo_sym1,foo_sym2)

На практике as is это реализовать нельзя, потому что там символов будет
целый гигбайт.  В процессе обдумывания компактная схема вероятностного
представления "множества символов" с односторонней ошибкой не хуже 10^{-3}
и расходом порядка 12 бит на символ.

> > Надо как-то обеспечить бинарную совместимость (на уровне зависимостей).
> > Ясно что сейчас она по большому счёту никак не обеспечена, а затея
> > с нашенскими version scripts нужно признать в лучшем случае half
> > successful, а по гамбургскому счету она себя не оправдала.
> 
> К сожалению :(

Ну как сказать.  Если для всех библиотек аккуратно поддерживать version
scripts то будет хорошая бинарная совместимость.  Но это аргумент того
же рода что если все программы хорошо продумать и грамотно написать то
получится надёжная конструкция которую вообще менять не надо и которая
будет до конца работать.

А если конструкция разваливается то как бо и не грех подпереть
её палкой.  Без сожаления.

> > Так что 
> > видимо придётся решаться на крутые меры.
> 
> Предполагается ли Requires проставляться на полный хэш символов библиотеки, с 
> которой слинкован бинарник при сборке, или только на минимально необходимый и 
> достаточный хэш по факту используемых символов из этой библиотеки?

Полный набор символов.

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

Re: [devel] symbols into dependencies

[Dmitry V. Levin]

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

On Mon, Nov 16, 2009 at 03:16:42AM +0300, Alexey Tourbin wrote:
[...]
> Да, "концептуальная" модель именно такая -- отслеживать символы
> внутри сонейма.
> 
> Provides: (libfoo.so.1;foo_sym1,foo_sym2,foo_sym3,...)
> Requires: (libfoo.so.1;foo_sym1,foo_sym2)

To match ELF semantics, we have to implement smth more complicated:

libfoo Provides(ELF): foo_sym1,foo_sym2,...
libbar Provides(ELF): bar_sym1,bar_sym2,...
client Requires(ELF): libfoo,libbar:foo_sym1,...,bar_sym1,...

And there is also symbol versioning that makes the picture even more
complex.


-- 
ldv

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

Re: [devel] symbols into dependencies

[Alexey Tourbin]

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

On Mon, Nov 16, 2009 at 03:27:23AM +0300, Dmitry V. Levin wrote:
> On Mon, Nov 16, 2009 at 03:16:42AM +0300, Alexey Tourbin wrote:
> [...]
> > Да, "концептуальная" модель именно такая -- отслеживать символы
> > внутри сонейма.
> > 
> > Provides: (libfoo.so.1;foo_sym1,foo_sym2,foo_sym3,...)
> > Requires: (libfoo.so.1;foo_sym1,foo_sym2)
> 
> To match ELF semantics, we have to implement smth more complicated:
> 
> libfoo Provides(ELF): foo_sym1,foo_sym2,...
> libbar Provides(ELF): bar_sym1,bar_sym2,...
> client Requires(ELF): libfoo,libbar:foo_sym1,...,bar_sym1,...

So what is your model here?  Providing global symbols (without soname
context) is wrong: until the library is open and mmap'd, a symbol
means nothing.  It is just a name clash until then.  A collision.

So, to match ELF semantics, which is to allow symbols be moved across
the libraries, the model can be like this:

libfoo Provides(ELF): libfoo:foo_sym1,foo_sym2,...
libbar Provides(ELF): libbar:bar_sym1,bar_sym2,...
client Requires(ELF): libfoo,libbar:foo_sym1,...,bar_sym1,...

To resolve the Requires dependency is then to check that each symbol
foo_sym1,...,bar_sym1,... can be resolved into at least one _required_
library.  Or, in terms of sets, requires set should be a subset of the
union of provides sets, with the union calculated for the appropriate
sonames.

However, if we consider "tegent problem" again, we have to admit that
this whole blasted thing still does not provide close-enough ELF
semantics.  The problem is that "tgetent" was part of libncurses,
and then libtinfo emerged as a separate library.  And older binaries
are not linked with libtinfo, so it won't be possible to resolve
their undefined symbols against the _required_ libraries.

Look, the next step in improving the model is to implement recursive
symbols lookup (i.e. "passing on" of symbols down the river).  Now,
if you think about this a few more minutes, you have to recognize
that we are actually going to reimplement some parts of dynamic linker
within rpm dependency mechanism.

> And there is also symbol versioning that makes the picture even more
> complex.

So, to follow ELF semantics the way dynamic linker does, you simply
end up with reimplementing certain parts of the dynamic linker.  And not
only the linker, but special kind of dependencies are required to mimic
certain ELF data structures (e.g. set-union).  Which is indeed complicated.

I argue that we do not follow ELF semantics that much closely.
The whole thing should be boiled down to a much simpler model.

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

Re: [devel] symbols into dependencies

[Dmitry V. Levin]

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

On Mon, Nov 16, 2009 at 12:14:43AM +0300, Alexey Tourbin wrote:
[...]
> Есть идея формировать зависимости на сонеймы с учетом символов.
> Это может выглядеть так:
> 
> 	%package -n libfoo
> 	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
> 
> 	%package -n foo
> 	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная строка)
> 
> То есть реализовать зависимости специального вида, которые представляют
> собой "множество строк" (символов).  Вместо обычного сравнения версий
> для таких зависимостей будет выполняться проверка, что requires set
> является подмножеством provides set.

Please do not over-optimize here.
For example, have a look at /bin/ls ELF executable:

$ readelf -d /bin/ls |awk '/NEEDED/{print $5}'
[librt.so.1]
[libcap.so.2]
[libtinfo.so.5]
[libacl.so.1]
[libc.so.6]
$ readelf -s /bin/ls |grep tgetent
    36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND tgetent

Where does the "tgetent" symbol come from?  Dynamic linker will be
sufficed if at least one of abovementioned libraries will provide it.

Here is a more artificial example written to demonstrate ld.so behaviour:
$ echo 'int a(){return 1;}' >liba.c &&
gcc -fpic -shared liba.c -o liba.so &&
echo 'int b(){return 2;}' >libb.c &&
gcc -fpic -shared libb.c -o libb.so &&
echo 'int main(){return a()+b();}' >exe.c &&
gcc exe.c -L. -la -lb -o exe &&
LD_LIBRARY_PATH=. ./exe; echo $?;
echo 'int b(){return 10;}' >liba.c &&
gcc -fpic -shared liba.c -o liba.so &&
echo 'int a(){return 20;}' >libb.c &&
gcc -fpic -shared libb.c -o libb.so &&
LD_LIBRARY_PATH=. ./exe; echo $?
3
30

That is, a needed ELF symbol may jump from one library to another.
And it had happened once with the "tgetent" symbol.

P.S. This issue is not an ALT Linux specific, so if we succeed to
work out a solution, it could be used by others.


-- 
ldv

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

Re: [devel] symbols into dependencies

[Alexey Tourbin]

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

On Mon, Nov 16, 2009 at 03:05:46AM +0300, Dmitry V. Levin wrote:
> On Mon, Nov 16, 2009 at 12:14:43AM +0300, Alexey Tourbin wrote:
> [...]
> > Есть идея формировать зависимости на сонеймы с учетом символов.
> > Это может выглядеть так:
> > 
> > 	%package -n libfoo
> > 	Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
> > 
> > 	%package -n foo
> > 	Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная строка)
> > 
> > То есть реализовать зависимости специального вида, которые представляют
> > собой "множество строк" (символов).  Вместо обычного сравнения версий
> > для таких зависимостей будет выполняться проверка, что requires set
> > является подмножеством provides set.
> 
> Please do not over-optimize here.
> For example, have a look at /bin/ls ELF executable:
> 
> $ readelf -d /bin/ls |awk '/NEEDED/{print $5}'
> [librt.so.1]
> [libcap.so.2]
> [libtinfo.so.5]
> [libacl.so.1]
> [libc.so.6]
> $ readelf -s /bin/ls |grep tgetent
>     36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND tgetent
> 
> Where does the "tgetent" symbol come from?  Dynamic linker will be
> sufficed if at least one of abovementioned libraries will provide it.

According to System V Application Binary Interface (gabi41.pdf),
tgetent comes from libcurses (p.125).  This gives strong evidence
for associating symbols with libraries they come from.

> Here is a more artificial example written to demonstrate ld.so behaviour:
> $ echo 'int a(){return 1;}' >liba.c &&
> gcc -fpic -shared liba.c -o liba.so &&
> echo 'int b(){return 2;}' >libb.c &&
> gcc -fpic -shared libb.c -o libb.so &&
> echo 'int main(){return a()+b();}' >exe.c &&
> gcc exe.c -L. -la -lb -o exe &&
> LD_LIBRARY_PATH=. ./exe; echo $?;
> echo 'int b(){return 10;}' >liba.c &&
> gcc -fpic -shared liba.c -o liba.so &&
> echo 'int a(){return 20;}' >libb.c &&
> gcc -fpic -shared libb.c -o libb.so &&
> LD_LIBRARY_PATH=. ./exe; echo $?
> 3
> 30
> 
> That is, a needed ELF symbol may jump from one library to another.
> And it had happened once with the "tgetent" symbol.

When a symbol is moved to another library, some programs might need
relinking, while some might still work.

Let's see what happens if a symbol is moved from libA to libB.  The
programs that use the symbol and linked only to libA go broke, right?
But programs which are linked to both libA and libB are fine.
Do you mean it is possible to handle these cases differently?

To sum up, when a function is moved to another library, the ABI is
changed, and the programs should be relinked.  It is only by chance
that some programs might still work.

> P.S. This issue is not an ALT Linux specific, so if we succeed to
> work out a solution, it could be used by others.

They don't care.  Otherwise they'd come with something more smart. :)

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

Re: [devel] symbols into dependencies

[Sergey Vlasov]

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

On Mon, Nov 16, 2009 at 03:44:38AM +0300, Alexey Tourbin wrote:
> When a symbol is moved to another library, some programs might need
> relinking, while some might still work.
> 
> Let's see what happens if a symbol is moved from libA to libB.  The
> programs that use the symbol and linked only to libA go broke, right?

But if libA is linked with libB, the symbol will still be available
even for such programs.

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

Re: [devel] symbols into dependencies

[Dmitry V. Levin]

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

On Mon, Nov 16, 2009 at 12:46:01PM +0300, Sergey Vlasov wrote:
> On Mon, Nov 16, 2009 at 03:44:38AM +0300, Alexey Tourbin wrote:
> > When a symbol is moved to another library, some programs might need
> > relinking, while some might still work.
> > 
> > Let's see what happens if a symbol is moved from libA to libB.  The
> > programs that use the symbol and linked only to libA go broke, right?
> 
> But if libA is linked with libB, the symbol will still be available
> even for such programs.

Yes, that was exactly the case with the tgetent migration.

What I want to highlight here is that our upcoming ELF deps should not
break valid symbol migrations.


-- 
ldv

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

Re: [devel] symbols into dependencies

[Alexey Tourbin]

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

On Mon, Nov 16, 2009 at 01:48:28PM +0300, Dmitry V. Levin wrote:
> On Mon, Nov 16, 2009 at 12:46:01PM +0300, Sergey Vlasov wrote:
> > On Mon, Nov 16, 2009 at 03:44:38AM +0300, Alexey Tourbin wrote:
> > > When a symbol is moved to another library, some programs might need
> > > relinking, while some might still work.
> > > 
> > > Let's see what happens if a symbol is moved from libA to libB.  The
> > > programs that use the symbol and linked only to libA go broke, right?
> > 
> > But if libA is linked with libB, the symbol will still be available
> > even for such programs.
> 
> Yes, that was exactly the case with the tgetent migration.
> 
> What I want to highlight here is that our upcoming ELF deps should not
> break valid symbol migrations.

On the other hand, we can simply assume that symbols should not be moved
across the libraries.  The worst thing that can happen then (if a symbol
does move) is that we need to rebuild a bunch of packages, only to
relink their binaries and update dependencies.

However, note that, as per tgetent, the binaries are actually going to
change upon relinking.  This indicates that the ABI has changed, too.
So the rebuild is not completely useless.

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

Re: [devel] symbols into dependencies

[Damir Shayhutdinov]

> On the other hand, we can simply assume that symbols should not be moved
> across the libraries.  The worst thing that can happen then (if a symbol
> does move) is that we need to rebuild a bunch of packages, only to
> relink their binaries and update dependencies.
>
> However, note that, as per tgetent, the binaries are actually going to
> change upon relinking.  This indicates that the ABI has changed, too.
> So the rebuild is not completely useless.

Have you thought about C++ libraries and their mangling? And the fact
that many of C++ exported symbols in such libraries are not, in fact,
the part of the API, they are only exported because C++ cannot control
their visibility on the ELF symbol level. I'm talking about private
methods of classes.

Or C++ libraries aren't worthy enough to consider?

Re: [devel] symbols into dependencies

[Alexey Tourbin]

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

On Mon, Nov 16, 2009 at 03:01:03PM +0300, Damir Shayhutdinov wrote:
> > On the other hand, we can simply assume that symbols should not be moved
> > across the libraries.  The worst thing that can happen then (if a symbol
> > does move) is that we need to rebuild a bunch of packages, only to
> > relink their binaries and update dependencies.
> >
> > However, note that, as per tgetent, the binaries are actually going to
> > change upon relinking.  This indicates that the ABI has changed, too.
> > So the rebuild is not completely useless.
> 
> Have you thought about C++ libraries and their mangling? And the fact
> that many of C++ exported symbols in such libraries are not, in fact,
> the part of the API, they are only exported because C++ cannot control
> their visibility on the ELF symbol level. I'm talking about private
> methods of classes.

I don't get what you're trying to say, sorry.
There is nothing special about C++.

> Or C++ libraries aren't worthy enough to consider?

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

Re: [devel] symbols into dependencies

[Sergey Vlasov]

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

On Mon, Nov 16, 2009 at 03:01:03PM +0300, Damir Shayhutdinov wrote:
> > On the other hand, we can simply assume that symbols should not be moved
> > across the libraries.  The worst thing that can happen then (if a symbol
> > does move) is that we need to rebuild a bunch of packages, only to
> > relink their binaries and update dependencies.

Do we care about binary-only apps which we cannot rebuild - would
their repackaging in the RPM form become impossible?

> Have you thought about C++ libraries and their mangling? And the fact
> that many of C++ exported symbols in such libraries are not, in fact,
> the part of the API, they are only exported because C++ cannot control
> their visibility on the ELF symbol level. I'm talking about private
> methods of classes.

Private methods can still be part of the public ABI - e.g., if a
public inline calls a private non-inline method, the resulting
executable will have a reference to the "private" symbol.

C++ libraries have yet another property which is unusual for C
libraries - they typically use weak symbols.

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

Re: [devel] symbols into dependencies

[Alexey Tourbin]

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

On Mon, Nov 16, 2009 at 03:50:29PM +0300, Sergey Vlasov wrote:
> On Mon, Nov 16, 2009 at 03:01:03PM +0300, Damir Shayhutdinov wrote:
> > > On the other hand, we can simply assume that symbols should not be moved
> > > across the libraries.  The worst thing that can happen then (if a symbol
> > > does move) is that we need to rebuild a bunch of packages, only to
> > > relink their binaries and update dependencies.
> 
> Do we care about binary-only apps which we cannot rebuild - would
> their repackaging in the RPM form become impossible?

The idea is that, at build time, we use something like ldd(1) to
find out how the dynamic linker resolves undefined symbols.  We then
get "the best possible" asoociation between symbols and libraries.

Prebuilt binaries are then different in a way that they can be
"underlinked": certain symbols can be transitively resolved into
libraries which are not specified as DT_NEEDED.

So it is quite possible to handle prebuilt binaries.  The only question
is whether extra dependencies (based on transitively resolved symbols)
should be added to the package.

> > Have you thought about C++ libraries and their mangling? And the fact
> > that many of C++ exported symbols in such libraries are not, in fact,
> > the part of the API, they are only exported because C++ cannot control
> > their visibility on the ELF symbol level. I'm talking about private
> > methods of classes.
> 
> Private methods can still be part of the public ABI - e.g., if a
> public inline calls a private non-inline method, the resulting
> executable will have a reference to the "private" symbol.
> 
> C++ libraries have yet another property which is unusual for C
> libraries - they typically use weak symbols.

Anyway, the idea is to find out "what the linker would do".

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

Re: [devel] symbols into dependencies

[Stanislav Ievlev]

Возможно эта схема и не очень удобна для бинарных библиотек, но зато
,как мне кажется, подошла бы для RPC подобных систем типа DBUS.

16 ноября 2009 г. 0:14 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Sun, Nov 15, 2009 at 10:00:02PM +0200, Led wrote:
>> "Точечные обновления" могут "гарантированно ломаються" даже со всеми
>> предлагаемыми костылями и зоопарком libfooN (где N - разные циферки). Пример:
>>
>> app собран с libfoo.so.1.0, соответственно слинкован с libfoo.so.1 и имеет
>> зависимость на  libfoo.so.1
>>
>> далее, появляется libfoo.so.1.1 (полностью обратно совместимая с
>> libfoo.so.1.0).
>>
>> далее, появляется новый app, собран с libfoo.so.1.1, соответственно слинкован
>> с libfoo.so.1 и имеет зависимость на  libfoo.so.1
>>
>> далее появляетесь вы, делаете "точечное обновление" app - всё отлично
>> обновляется.
>>
>> запускаете app - упс! "неизвестный символ". app "упало" :(
>>
>> SharedLibsPolicy в таком случае - никак не помогает :(
>
> Есть идея формировать зависимости на сонеймы с учетом символов.
> Это может выглядеть так:
>
>        %package -n libfoo
>        Provides(auto): libfoo.so.1 = set:0123abcd...(очень длинная строка)
>
>        %package -n foo
>        Requires(auto): libfoo.so.1 >= set:abcd0123...(умеренно длинная строка)
>
> То есть реализовать зависимости специального вида, которые представляют
> собой "множество строк" (символов).  Вместо обычного сравнения версий
> для таких зависимостей будет выполняться проверка, что requires set
> является подмножеством provides set.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>

Re: [devel] SharedLibsPolicy

[Sergey Vlasov]

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

On Sun, Nov 15, 2009 at 10:00:02PM +0200, Led wrote:
> "Точечные обновления" могут "гарантированно ломаються" даже со всеми 
> предлагаемыми костылями и зоопарком libfooN (где N - разные циферки). Пример:
> 
> app собран с libfoo.so.1.0, соответственно слинкован с libfoo.so.1 и имеет 
> зависимость на  libfoo.so.1
> 
> далее, появляется libfoo.so.1.1 (полностью обратно совместимая с 
> libfoo.so.1.0).
> 
> далее, появляется новый app, собран с libfoo.so.1.1, соответственно слинкован 
> с libfoo.so.1 и имеет зависимость на  libfoo.so.1
> 
> далее появляетесь вы, делаете "точечное обновление" app - всё отлично 
> обновляется.
> 
> запускаете app - упс! "неизвестный символ". app "упало" :(

В хороших библиотеках это лечится механизмом symbol versioning - в
этом случае в пакетах, использующих новые функции, появится
зависимость не просто на libfoo.so.1, а на libfoo.so.1(FOO_1_1), и по
зависимостям вытянется и новая библиотека.  Естественно, применение
этого механизма требует определённой дисциплины, которая у апстрима во
многих случаях отсутствует - тогда, если мантейнер не исправил это за
апстримом, и вылезают проблемы при точечном обновлении.

> SharedLibsPolicy в таком случае - никак не помогает :(

Правильно, потому что SharedLibsPolicy не имеет отношения к случаю,
когда библиотека обновляется без изменения soname - там описываются
меры по организации смены soname, предположительно минимизирующие
количество проблем при выполнении dist-upgrade.

> > Иногда, потому что ряд критичных пакетов (вроде libdb) могут
> > присутствовать в репозитории несколькими версиями одновременно.
> 
> ls -1 /lib64/libdb*
> /lib64/libdb-4.4.so
> /lib64/libdb-4.5.so
> /lib64/libdb-4.7.so
> 
> Неудачный пример. Формально это разные библиотеки, с разными именами, без 
> версии после "so"

Точнее, это разные версии по сути одной библиотеки - Berkeley DB, но с
несовместимыми ABI (что отражается в смене soname) и в некоторых
случаях не вполне совместимыми API (иногда программы приходится
патчить для сборки с новой версией).  Как раз этот случай и
описывается в SharedLibsPolicy.

> > Но написать такое приложение -- да, было бы полезно. Не хочешь взяться за
> > это? :)
> 
> А смысл? Следить за бардаком? ИМХО нужно просто не устраивать бардак.

Бардак, как правило, уже устроен апстримными разработчиками, и
остаётся только пытаться как-то с ним бороться в рамках репозитория.

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

Re: [devel] SharedLibsPolicy

[Led]

On Monday, 16 November 2009 00:01:41 Sergey Vlasov wrote:
> On Sun, Nov 15, 2009 at 10:00:02PM +0200, Led wrote:
> > "Точечные обновления" могут "гарантированно ломаються" даже со всеми
> > предлагаемыми костылями и зоопарком libfooN (где N - разные циферки).
> > Пример:
> >
> > app собран с libfoo.so.1.0, соответственно слинкован с libfoo.so.1 и
> > имеет зависимость на  libfoo.so.1
> >
> > далее, появляется libfoo.so.1.1 (полностью обратно совместимая с
> > libfoo.so.1.0).
> >
> > далее, появляется новый app, собран с libfoo.so.1.1, соответственно
> > слинкован с libfoo.so.1 и имеет зависимость на  libfoo.so.1
> >
> > далее появляетесь вы, делаете "точечное обновление" app - всё отлично
> > обновляется.
> >
> > запускаете app - упс! "неизвестный символ". app "упало" :(
>
> В хороших библиотеках это лечится механизмом symbol versioning - в
> этом случае в пакетах, использующих новые функции, появится
> зависимость не просто на libfoo.so.1, а на libfoo.so.1(FOO_1_1), и по
> зависимостям вытянется и новая библиотека.

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

> Естественно, применение 
> этого механизма требует определённой дисциплины, которая у апстрима во
> многих случаях отсутствует - тогда, если мантейнер не исправил это за
> апстримом, и вылезают проблемы при точечном обновлении.
>
> > SharedLibsPolicy в таком случае - никак не помогает :(
>
> Правильно, потому что SharedLibsPolicy не имеет отношения к случаю,
> когда библиотека обновляется без изменения soname - там описываются
> меры по организации смены soname, предположительно минимизирующие
> количество проблем при выполнении dist-upgrade.

Правильно. Поэтому приводить "обновлкние без изменения soname" в качестве 
аргумента в пользу SharedLibsPolicy - глупо.

>
> > > Иногда, потому что ряд критичных пакетов (вроде libdb) могут
> > > присутствовать в репозитории несколькими версиями одновременно.
> >
> > ls -1 /lib64/libdb*
> > /lib64/libdb-4.4.so
> > /lib64/libdb-4.5.so
> > /lib64/libdb-4.7.so
> >
> > Неудачный пример. Формально это разные библиотеки, с разными именами, без
> > версии после "so"
>
> Точнее, это разные версии по сути одной библиотеки - Berkeley DB, но с
> несовместимыми ABI (что отражается в смене soname) и в некоторых
> случаях не вполне совместимыми API (иногда программы приходится
> патчить для сборки с новой версией).

Вот поэтому я и сказал: "ФОРМАЛЬНО - это разные библиотеки" (исходя из имён 
файлов). Про то, что по факту это разные версии одной библиотеки - я в 
курсе:)

> Как раз этот случай и 
> описывается в SharedLibsPolicy.
>
> > > Но написать такое приложение -- да, было бы полезно. Не хочешь взяться
> > > за это? :)
> >
> > А смысл? Следить за бардаком? ИМХО нужно просто не устраивать бардак.
>
> Бардак, как правило, уже устроен апстримными разработчиками, и
> остаётся только пытаться как-то с ним бороться в рамках репозитория.

Бардак в апстримах обычно значительно меньше, чем о нём здесь принято 
говорить:)

-- 
Led

Re: [devel] SharedLibsPolicy

[Igor Vlasenko]

On Sun, Nov 15, 2009 at 01:55:45AM +0300, Денис Смирнов wrote:
> Диагностировать автоматически подобную граблю возможно, хотя это и требует
> усилий. Поэтому борьбу я бы предпочел сконцентрировать в этой области. а
> не отказываться от SharedLibsPolicy (такой отказ является лечение головной
> боли гильотиной).

Такие тесты под репокоп написать можно,

Предлагаю 3 теста

1) a lib has no client apps
-для поиска мусора

2) client app is linked with the older version of a lib
-для стимулирования пересборки

3) recursive deps include 2 versions of the same lib
-must be.

но это кусок работы. Я сейчас по уши в NMU,
не раньше чем закончу с ним.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] SharedLibsPolicy

[Michael Shigorin]

On Sun, Nov 15, 2009 at 02:08:43PM +0200, Igor Vlasenko wrote:
> 1) a lib has no client apps -для поиска мусора

Потенциального, потому как могут быть ещё случаи dlopen()
(хотя и слабо верится, что lib* кто-то будет паковать
исключительно для такого, а плагины будут называться lib*).

> 2) client app is linked with the older version of a lib
> -для стимулирования пересборки
> 3) recursive deps include 2 versions of the same lib
> -must be.

Да, было бы неплохо.

> но это кусок работы. Я сейчас по уши в NMU, не раньше чем
> закончу с ним.

Спасибо и за предложение!

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

Re: [devel] SharedLibsPolicy

[Michael Shigorin]

On Sun, Nov 15, 2009 at 08:39:17PM +0200, Alexander Bokovoy wrote:
> > > 1) a lib has no client apps -для поиска мусора
> > Потенциального, потому как могут быть ещё случаи dlopen()
> > (хотя и слабо верится, что lib* кто-то будет паковать
> > исключительно для такого, а плагины будут называться lib*).
> $  ls /usr/lib/qt4/plugins/*/|egrep '^lib'|wc -l
> 17
> и это у меня, без полной установки KDE/Qt4.
> Все Qt4-модули называются lib*.so.

Надо же, а у меня xmms-ные плагины. :)  Думал, что достаточно
однозначно сказал -- lib* в качестве имён _пакетов_, а не файлов.
Виноват.

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

Re: [devel] SharedLibsPolicy

[Денис Смирнов]

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

On Sun, Nov 15, 2009 at 03:30:42PM +0200, Michael Shigorin wrote:

MS> Потенциального, потому как могут быть ещё случаи dlopen()
MS> (хотя и слабо верится, что lib* кто-то будет паковать
MS> исключительно для такого, а плагины будут называться lib*).

Как бы плагины не назывались -- им не место в %_libdir

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy

[Michael Shigorin]

On Sun, Nov 15, 2009 at 10:36:02PM +0300, Денис Смирнов wrote:
> MS> Потенциального, потому как могут быть ещё случаи dlopen()
> MS> (хотя и слабо верится, что lib* кто-то будет паковать
> MS> исключительно для такого, а плагины будут называться lib*).
> Как бы плагины не назывались -- им не место в %_libdir

Я и имел в виду, что если пакет называется lib* и содержимое
лежит в %_libdir/*.so.*, то оно вряд ли предназначено
_исключительно_ для dlopen() и нормальным образом не ловится.


On Sun, Nov 15, 2009 at 10:36:33PM +0300, Konstantin Pavlov wrote:
> > > 1) a lib has no client apps -для поиска мусора
> > Потенциального, ...
> Не стоит ещё забывать и про проприетарные бинарники.

Об этом и говорю -- что решать тут человекам, но заглянуть
в текущее состояние было бы удобно.

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

Re: [devel] SharedLibsPolicy

[Konstantin Pavlov]

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

On Sun, Nov 15, 2009 at 03:30:42PM +0200, Michael Shigorin wrote:
> On Sun, Nov 15, 2009 at 02:08:43PM +0200, Igor Vlasenko wrote:
> > 1) a lib has no client apps -для поиска мусора
> 
> Потенциального, ...

Не стоит ещё забывать и про проприетарные бинарники.

-- 
> >if [ ! -f "/usr/sbin/foo2zjs_download_fw" ]; then тра-ля-ля
> Попробуйте:
> VAR="/usr/sbin/foo2zjs_download_fw"
> if [ ! -f "$VAR" ]; then тра-ля-ля
Именно тра-ля-ля и породило зависимость.
		-- ldv in devel@

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

Re: [devel] SharedLibsPolicy

[Денис Смирнов]

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

On Sun, Nov 15, 2009 at 02:08:43PM +0200, Igor Vlasenko wrote:

IV> Такие тесты под репокоп написать можно,
IV> Предлагаю 3 теста
IV> 1) a lib has no client apps
IV> -для поиска мусора

Это не мусор, а compat-библиотеки. Это очень вредный тест, потому что их
будут удалять :) А compat-библиотеки часто нужны для проприетарных
поделий, например.

IV> 2) client app is linked with the older version of a lib
IV> -для стимулирования пересборки

Ага!

IV> 3) recursive deps include 2 versions of the same lib
IV> -must be.

При этом тот из пакетов кто тянет более старую версию библиотеки должен
быть помечен как 'error', с требованием быстрой-быстрой пересборки :)

IV> но это кусок работы. Я сейчас по уши в NMU,
IV> не раньше чем закончу с ним.

Все равно спасибо!

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Денис Смирнов]

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

On Fri, Nov 13, 2009 at 11:36:32AM +0300, Valery V. Inozemtsev wrote:

VVI> как говорится утро вечера мудренее... по мотивам #22272 родилась у меня
VVI> такая сказочка, назовем ее "Фиговый листочек SharedLibsPolicy, или слава
VVI> богу что мы не Debian". а теперь доказательство в примерах.

1. Есть рекомендация чтобы пакет -devel был одним единственным. Таким
обрзом проблема "разные пакеты собираются в репозитории с разной версией
библиотеки" не маскируется, а приводит к несобираемости этих пакетов, и,
соответственно, вылету их из репо в течении 3-х месяцев.

2. Точечные обновления, к сожалению, очень часто приводят к проблемам. Это
известный факт. Они должны работать хоть как-то, потому что иногда
являются необходимыми (и специалист может решить эти проблемы во многих
случаях).

VVI> Пример 2:
VVI> libpolkit/libpolkit1. полиси соблюдены, пожалуйста собирайте KDE4 с
VVI> polkit, gnome-2.28 с polkit1. но тут опять бяда - кто то из них будет
VVI> работать не так, как предполагалось. оказывается сам по себе polkit
VVI> работать не может, ему нужен ConsoleKit и рабочим будет тот polkit с
VVI> которым слинкован ConsoleKit

Conflicts, увы, иногда необходимы.

Provides: libpolkit = %version
Conflicts: libpolkit < %version
Conflicts: libpolkit > %version

Да, это _лучше_ чем именование без версии, хотя с точки зрения логики это
идентично, но с точки зрения глючной поделки apt -- нет.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Anton Farygin]

14.11.2009 23:31, Денис Смирнов пишет:
> On Fri, Nov 13, 2009 at 11:36:32AM +0300, Valery V. Inozemtsev wrote:
>
> VVI>  как говорится утро вечера мудренее... по мотивам #22272 родилась у меня
> VVI>  такая сказочка, назовем ее "Фиговый листочек SharedLibsPolicy, или слава
> VVI>  богу что мы не Debian". а теперь доказательство в примерах.
>
> 1. Есть рекомендация чтобы пакет -devel был одним единственным. Таким
> обрзом проблема "разные пакеты собираются в репозитории с разной версией
> библиотеки" не маскируется, а приводит к несобираемости этих пакетов, и,
> соответственно, вылету их из репо в течении 3-х месяцев.
>
> 2. Точечные обновления, к сожалению, очень часто приводят к проблемам. Это
> известный факт. Они должны работать хоть как-то, потому что иногда
> являются необходимыми (и специалист может решить эти проблемы во многих
> случаях).

К сожалению, в последнее время Linux'ом, и ALT Linux в частности часто 
пользуется не-специалист, следуя рекомендациям (советам) других 
не-специалистов. Риск убить систему, используя точечные обновления при 
наличии SharedLibs разных версий - крайне велик для не-специалиста (да и 
для специалиста тоже).

Re: [devel] SharedLibsPolicy или хорошо что мы не Debian

[Michael Shigorin]

On Sun, Nov 15, 2009 at 02:14:15AM +0300, Anton Farygin wrote:
> Риск убить систему, используя точечные обновления при наличии
> SharedLibs разных версий - крайне велик для не-специалиста (да
> и для специалиста тоже).

На практике так скорее подранить, а вот вынеся полсистемы --
действительно убить в неподъёмный для неспециалиста вид.

Сколько у нас таких идиотских библиотек вроде libpolkit,
а сколько остальных libfftw*.  Вот тебе и пропорция.

PS: это и к dist-upgrade относится, причём GUI у нас
не подстрахуют.

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