[devel] 4.1 FAILED srpm=rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 19:34:10 21.03.2009 UTC+03 when rider на altlinux.com did gyre and gimble:
> 
>  >> 1) Достаточно трудоёмко держать несколько версий библиотек. Впрочем,
>  >> с git-ом легче: git clone, старый оставили как есть, в новом
>  >> переименовали.
> 
>  AF> Там не только переименовать, но и спек придётся подчистить... да,
>  AF> геммороя много.  Мне больше нравится (в ряде случаев) схема
>  AF> lib%name и lib%name-compat,
> 
> У этой схемы есть проблема: не получается бэкпортить библиотеки. Если в
> бранче лежит libfoo17, то не проблема положить туда libfoo18. А как
> называть такой новый libfoo, если в бранче уже есть libfoo?
> libfoo-tapmoc? :)

Какой смысл иметь возможность бэкпортить библиотеки, с которыми никто не 
может слинковаться? (без devel пакета).

> 
> Кроме того, возникает вопрос проставления правильных
> provides/obsoletes. Для %soname проще.

В том то и счастье, что не надо ничего проставлять. Всё проставляется само.
$ rpm -q --provides libImageMagick-compat
libMagick++.so.1
libMagickCore.so.1
libMagickWand.so.1
libImageMagick-compat = 6.4.8.1-alt3


> 
>  >> 2) Потенциальная возможность загрузить две разные версии библиотеки
>  >> в процесс, со всеми вытекающими.
> 
>  AF> Да, тоже неприятно. Как эту проблему решают в debian ?
> 
> Частично решают ручным управлением transition'ами: несколько библиотек
> может сосуществовать недолгое время, так как мейнтейнеров пинают на
> пересборку.

Т.е. - фактически тот же compat, но в менее формальном виде.

> 
> В backports никак не решают.

В backports нет библиотек с разными soname ? Или в Debian backports 
никак не формализован ?