[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