Macports has ports of both openssl and libressl but they are mutually exclusive as they install overlapping files. Binary precompiled packages are built with openssl, so folks using libressl have to build ports depending on libssl from source. Not convinient, but still manageable.
Openssl keeps adding new features which are not immediately available in libressl. That affects programs using libssl. Quite often ports require libressl-specific patches just to be able to be built with libressl. Some ports declare explicit dependency on openssl, and if I have libressl installed, I am stuck in this situation, as openssl cannot be installed alongside with libressl. The most recent example: port sync && port outdated showed py38-cryptography and py39-cryptography as outdated py38-cryptography 2.9.2_0 < 3.4.7_1 py39-cryptography 2.9.2_0 < 3.4.7_1 Binary packages are built with openssl, so rev-upgrade attempts to rebuild them. It worked with version 2.9.2, but 3.4.7 pulls in rust and cargo. Pre-built rust has to be rev-upgraded because of libssl, and fails to build as it requires openssl, and I have libressl installed, and it conflicts with openssl. This is where I hit the wall. I am not using py-cryptography directly, I need py38/39-cryptography as a dependency of ansible. It looks like if I want to continue using ansible on this system and have it managed by macports, I have to give up on libressl and install openssl. Or install ansible outside of macports. I guess there are more ports in such situation. Is macports as a project going to drop support for libressl? (Several linux distros, e.g. gentoo and void, did it recently). It would be nice to have libressl in macports, but if the project does not have resources to support it, would it be better just to state that explicitly? It would prevent unnecessary expectations. Thanks, Kastus
