Небольшая заметочка о том, как Conan вычисляет зависимости при сборке пакета или проекта.

И так, у нас в кэше Conan есть два пакета динамической библиотеки OpenSSL, версии 1.1.0c и 1.1.0d. User - odant, канал - stable. И есть пакет JScript, для которого требуется OpenSSL версии большей чем 1.1.0a.

Теперь собираем проект использующий этот JScript и OpenSSL (который требуется для JScript). При сборке явно указываем используемые версии: jscript/11.13.0.1@odant/stable и openssl/1.1.0d@odant/stable. Все соберется и будет работать, даже если при сборке JScript существовала только версия OpenSSL 1.1.0c. Версия OpenSSL 1.1.0d будет использована как совместимая с JScript (с точки зрения разрешения зависимостей Conan).

Самое интересное, что можно менять не только версию, но и канал пакета. Хотя канал пакета OpenSSL в рецепте сборки JScript указан stable (openssl/[>1.1.0a]@odant/stable). Пользователя сменить уже нельзя.

И немного о грустном. Для вычисления допустимой версии Conan использует схему semantic versioning. OpenSSL же использует свою модель версии, с буковкой на конце. Так что OpenSSL версии 1.1.0[a-z] с точки зрения Conan считаются допустимыми, а версия 1.1.1b уже нет. Хоть и версия 1.1.1b обратно совместима с версией 1.1.0a (Проект и JScript, скомпонованные с OpenSSL 1.1.0g нормально запускается с OpenSSL 1.1.1b)

Есть и хорошая новость. Следующий мажорный релиз OpenSSL уже будет использовать обычную схему semantic versioning. Тесты тут. Проверялось на Conan версии 1.15.0