On Sat, Dec 23, 2017 at 12:53:30AM +0100, Alexey Gladkov wrote:
> On Sat, Dec 23, 2017 at 01:37:09AM +0300, Dmitry V. Levin wrote:
> > Получается, что единственное доступное нам решение задачи, чтобы в nss
> > были те же сертификаты, что и в openssl с gnutls - это заменить
> > libnssckbi.so, который использует nss, ссылкой на альтернативного
> > провайдера (/usr/lib64/pkcs11/p11-kit-trust.so), который это реализует.
> > 
> > Можно, конечно, управлять этой ссылкой с помощью механизма альтернатив,
> > но я не вижу в этом смысла.
> > Если какая-то версия nss перестанет работать с p11-kit-trust.so, то эту
> > ссылку придётся временно заменить на файл, поставляемый с libnss, до тех
> > пор, пока p11-kit-trust.so снова не заработает, после чего ссылку можно
> > будет вернуть, поставив соответствующие зависимости (в данном случае,
> > наверное, конфликты).
> > Чем в этой ситуации поможет механизм альтернатив?
> 
> Я хотел бы иметь возможность использовать именно libnssckbi.so без
> пересборки собственного пакета. Мне это хочется по ряду причин.

В таком случае альтернатива на libnssckbi.so -- это то, что надо.
Но что это за причины?
И почему libnssckbi.so находится непосредственно в %_libdir?


-- 
ldv