state of libressl in macports

[Kastus Shchuka]

Thanks Ryan!

I have filed https://trac.macports.org/ticket/62858 for rust.

> On May 10, 2021, at 4:30 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> You've summed up the situation nicely.
> 
> 
> On May 9, 2021, at 21:18, Kastus Shchuka wrote:
> 
>> 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.
> 
> Correct, our current situation with openssl and libressl is not optimal, not really what I would like to have. See https://trac.macports.org/ticket/54744. Nobody has volunteered to fix the situation. Anyone is welcome to do so. It would involve coming up with a proposal, discussing it on the macports-dev mailing list and reaching consensus about what should be done, and then doing it.
> 
> 
>> 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.
> 
> Often, when someone adds a port to MacPorts that requires openssl or an openssl-compatible library like libressl, they write the dependency as "port:openssl". This prevents libressl from being used. Currently there are a small number of ports in this situation:
> 
> $ port echo depends:'port:openssl($|\s)'
> calendar-contacts-server
> libaes_siv
> netdata
> netdata-dashboard
> ntpsec
> ophcrack
> rizin
> squid4
> sslscan
> rust
> msodbcsql17
> 
> Often, this occurs simply because the contributor was not aware of the issue, and switching the dependency to "path:lib/libssl.dylib:openssl" is all that's needed to allow libressl to be used if desired. Rarely, there are specific reasons why libressl is not compatible with a project; in that case, the Portfile should contain a comment line near the "port:openssl" dependency that explains why.
> 
> In the case of rust, it declares both a library dependency on path:lib/libssl.dylib:openssl and a build dependency on port:openssl, which seems like nonsense to me:
> 
> $ port -v deps rust
> Full Name: rust @1.52.1_0
> Build Dependencies:   bin:git:git, path:bin/cmake:cmake, port:cctools, port:python39, port:openssl, port:pkgconfig, port:ninja, port:gmake, port:ccache
> Library Dependencies: port:libffi, path:lib/libssl.dylib:openssl
> 
> It seems like removing the port:openssl build dependency would be the correct thing to do, but I haven't tried to figure out why it's the way it is.
> 
> I recommend filing bug reports for any of these ports that do not already indicate in their comments a specific reason for incompatibility with libressl.
> 
> 
>> 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.
> 
> I don't think anyone's expressed any interest in dropping libressl support before. I wasn't aware that any Linux distros had dropped support for it, but I don't know anything else about what Linux distros are doing either. Do you know why they dropped libressl?