Thanks Ryan! I have filed https://trac.macports.org/ticket/62858 for rust.
> On May 10, 2021, at 4:30 PM, Ryan Schmidt <ryandes...@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?
