[MacPorts] #54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc.

[MacPorts]

#54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc.
-------------------------------+----------------------
  Reporter:  ryandesign        |      Owner:  jeremyhu
      Type:  defect            |     Status:  new
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:
Resolution:                    |   Keywords:
      Port:  libressl openssl  |
-------------------------------+----------------------

Comment (by RJVB):

 I'd vote against deprecating openssl or anything that looks like it - I
 don't think we can get around it as long as it's the de-facto SSL provider
 on Linux (= the platform for which so many of the ports in MacPorts are
 written). It doesn't really matter how technically inferior it is; as long
 as it's good enough to do the job it's probably the more practical and
 thus the better solution. I'm not interested in having to jump through all
 kinds of hoops to get a theoretically better SSL implementation while most
 of the software I work with was conceived to use OpenSSL and the majority
 of "my" ports depend on (or are dependencies of) Qt5 which is incompatible
 with LibreSSL.

 As expressed on another ticket, I'd vote for an approach with a build
 variant coupled with a mechanism to indicate incompatibility with either
 one of the alternative *SSL ports - probably via a PortGroup just because
 that's more practical to maintain than an implementation as a feature in
 "base". In fact I set out designing such an SSL PG a bit over 2y ago but
 gave up when I came to the conclusion that LibreSSL wasn't such a viable
 alternative to OpenSSL in practice.

 BTW, what do we know about mixing OpenSSL and LibreSSL in the address
 space of a single application, provided that no data is passed between
 implementations? IOW, can a Qt5 application (say, QupZilla) that uses
 OpenSSL via Qt APIs also use non-Qt libraries built to use LibreSSL (say,
 libcurl), or is that just asking for trouble?

--
Ticket URL: <https://trac.macports.org/ticket/54744#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS