On Thu, Oct 07, 2004 at 08:53:52PM +0400, Sergey V Turchin wrote:
> > Я уже собрал nspr-4.4.1.  Столкнулся с проблемой: libnspr4.so
> > конфликтует с /usr/lib/libnspr4.so ->
> > /usr/lib/mozilla/libnspr4.so, а библиотеки ни с кем конфликтовать
> > не должны.  Поэтому сделал soname libnspr4.so.4,
> Зачем soname портить?
> Из Mozilla уберется и все будет ок.

Потому что пакет libnspr не должен ни с кем конфликтовать.

Далее, если, например, в nspr-4.5.x задним числом изменится ABI (как
в libtiff-3.6), то можно будет изменить soname c libnspr4.so.4 на
libnspr4.so.4.5.

Далее, всё остальное будет _правильно_ пересобираться, т.е. при линковке
с -lnspr4 (как сейчас линкуются все, кто её носит с собой) будет
автоматически выставляться зависимость на libnspr4.so.4.  Т.е. пакеты,
пересобранные с libnspr-devel, будут явно требовать новый libnspr.
Если же оставить soname прежним, то пакеты, пересобранные c
libnspr-devel, могут вместо libnspr вытянуть либо mozilla, либо firefox,
либо firebird, т.к. эти пакеты предоставляют libnspr4.so.  При этом
пакеты могут попросту не работать (%add_findprov_lib_path сделает свое
черное дело).

Далее, как я понимаю, все "локальные" бинари, слинкованные со старым
libnsp4.so, будут продолжать работать при установленном пакете
libnspr4-devel.

Т.е. я думаю, что "ужесточение" soname -- это наиболее мягкий вариант
(возможного) привнесения libnspr в системные библиотеки.