[devel] SharedLibsPolicy

[Sergey Vlasov]

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.

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

Бардак, как правило, уже устроен апстримными разработчиками, и
остаётся только пытаться как-то с ним бороться в рамках репозитория.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20091116/4b04fe0d/attachment.bin>