[devel] [cyber] I: Sisyphus-20191130 x86_64 beehive_status: +14 -7 (727)

[Paul Wolneykien]

В Mon, 2 Dec 2019 10:57:15 +0300
"Alexey V. Vissarionov" <gremlin на altlinux.org> пишет:

> On 2019-12-02 10:47:53 +0300, Michael Shigorin wrote:
> 
>  >>>> И тут выясняется, что заменить одну библиотеку на другую
>  >>>> можно -- слинкованнная с ней программа продолжит работать,
>  >>>> --- но нет гарантии, что apt выберет по умолчанию libnss,
>  >>>> а не libnss-gost  
>  >>> А что, если собирать libnss-gost вместе с libnss из одного
>  >>> srpm?  
>  >> Может быть и можно, но у меня сейчас возникла вот какая
>  >> гипотеза: а нельзя ли собирать libnss-gost с каким-то таким
>  >> disttag, чтобы apt не выбирал его для установки *без ведома
>  >> пользователя*?  
>  > Насколько понимаю, загвоздка не столько в апте, сколько в
>  > возможности (вполне реальной, не теоретической) разъезда ABI
>  > библиотек в случае необходимости сборки новой апстримной
>  > версии и невозможности оперативно обновить gost patch.  
> 
> В этом случае надо делать libnss-gost отдельной библиотекой,
> а не дублировать libnss с добавлением функций - тогда тот же
> firefox-gost будет требовать и libnss, и libnss-gost, а обычный
> firefox обойдется только libnss.

  С точки зрения обобщённой логики --- всё хорошо, а с точки зрения
архитектуры NSS не очень. Я же не добавляю каких-то новых функций,
никак не расширяю API libnss. Я именно что, предоставляю альтернативную
реализацию *того же самого* интерфейса, т.е. того же самого набора
функций, что и в libnss. Да и то, альтернативную только в 5% случаев.