[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