WIP: relax port:openssl to path:lib/libssl.dylib:openssl

[janstary]

These are exactly the ports that specify port:openssl
as opposed to path:lib/libssl.dylib:openssl,
which all the other ssl-dependent ports do.

This is work in progress.
Please test whether this breaks your port.

1. uninstall openssl and everything that depends on it
2. install libressl instead, providing libssl.dylib
3. rebuild you port with port -vs install
4. see how it works or breaks; please report here.

I'm testing on MacOS 10.13.2. with Xcode 9.2

[macportsbot]

Notifying maintainers:
@stromnov for port phantomjs.
@MarcusCalhoun-Lopez for port qt5, qt55, qt56, qt57, qt58, qt59.
@seanfarley for port fbthrift, folly.
@mkae for port qca.
@RJVB for port qca.
@RoddieKieley for port qpid-proton.

[RJVB]

Last time I tried to use libressl instead of openssl it didn't take long before I fled back to openssl (and abandoned my project to write an SSL PortGroup supposed to help choosing and possibly switching between SSL providers).

It's hardly feasible to switch, in practice because of ABI incompatibilities. That also means that testing a build with both SSL providers is a big and disruptive investment. As far as I'm concerned the burden to show libressl is a viable alternative dependency is therefore on those who'd like to see support for it, esp. for Qt5 ports and dependents because of https://trac.macports.org/ticket/51358#comment:6 (a quick search on "Qt5 and libressl" returned the trac ticket as the 2nd hit). See also https://github.com/voidlinux/void-packages/issues/5998 in case you want to venture into patching Qt.

I have however nothing against making port:qca-qt5 use the path-style depspec, provided someone can show it works when Qt itself is built to use the native Secure Transport framework.

[pmetzger]

I agree with @RJVB

[cjones051073]

As discussed on the mailing list, it was probably a mistake to use the "path:lib/ssl.dylib:openssl" syntax in the first place to deal with this, as libressl is not, and will not be, a direct drop in replacement for openssl.

I agree with this, to that end would vote for not merging this. Yes, the mistake has been made but we should not compound it further.

Instead, we should take the approach as discussed in

https://trac.macports.org/ticket/54744

[RoddieKieley]

I agree with @cjones051073 and taking the approach outlined in the comments of 54744; i.e.

• no deprecation of OpenSSL
• build variants for the *SSL ports

As far as I'm aware no other *SSL libraries have been utilized or tested with Qpid Proton thus far so I'd be hesitant to make it the default at this point in time.