В библиотеках openssl нет версионирования: $ rpm -q --provides libcrypto10 libcrypto = 1.0.2n-alt1 libcrypto.so.10()(64bit) А вот в Fedora, например, есть: $ rpm -q --provides openssl-libs libcrypto.so.1.1()(64bit) libcrypto.so.1.1(OPENSSL_1_1_0)(64bit) libcrypto.so.1.1(OPENSSL_1_1_0a)(64bit) libcrypto.so.1.1(OPENSSL_1_1_0c)(64bit) libcrypto.so.1.1(OPENSSL_1_1_0d)(64bit) libcrypto.so.1.1(OPENSSL_1_1_0f)(64bit) libcrypto.so.1.1(OPENSSL_1_1_0g)(64bit) Удивляюсь расхождению soname и отсутствию версий. Является ли это решение принципиальным или просто унаследованным. Если унаследованным, то подверженным ли изменению?
Зачем вам версионирование, и какой смысл сравнивать openssl 1.0 с openssl 1.1?
(В ответ на комментарий №1) > Зачем вам версионирование, и какой смысл сравнивать openssl 1.0 с openssl 1.1? Версионирование позволяет надеется на идентичность ABI. Из вопроса про 1.1 можно сделать вывод, что в сборке 1.1 будет версионирование? Я сравнивал просто для наглядности присутствия и отсутствия.
(In reply to comment #2) > (В ответ на комментарий №1) > > Зачем вам версионирование, и какой смысл сравнивать openssl 1.0 с openssl 1.1? > Версионирование позволяет надеется на идентичность ABI. У нас есть set-versions. > Из вопроса про 1.1 можно сделать вывод, что в сборке 1.1 будет версионирование? У 1.1 всё равно другой soname, можно и поэкспериментировать. В этом openssl всё не как у людей, и версионирование тоже: его генерит загадочный скрипт util/mkdef.pl
