[MacPorts] #54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc. (was: coexistence of libress, 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 ryandesign):

 Replying to [comment:1 jeremyhu]:
 > Yes, they have different dylib ids and are ABI incompatible (just like
 different versions of ffmpeg for example).  The problem here is no
 different than the issues encountered between using ffmpeg and ffmpeg-
 devel.

 That's a completely different situation, in most cases. The assumption
 with -devel ports is that it's the development version of the software and
 it has features and bug fixes not present in the stable version but is
 otherwise a drop-in replacement for the stable version. The user can
 receive binaries built on our buildbot with a stable version of a library
 and use them with the development version of the library on their system,
 assuming the library's `install_name` hasn't changed.

 In some cases, the development version may have a newer major library
 version number and thus a new `install_name`, which breaks the ability to
 use precompiled binaries, but only for the hopefully short duration of
 time until the stable version of the port is updated to the new version
 that has that same new major library version.

 The libressl/openssl situation is completely different because they always
 have and always will have completely different major library versions and
 therefore `install_name`s and are therefore never drop-in replacements for
 one another.

 > Furthermore, I suggest that we switch all dependents over to using
 libressl instead of openssl as the default.  There's no reason for us to
 continue to push an inferior implementation onto our users.  I've been
 using libressl exclusively for years now.

 In principle I have no problem with deprecating openssl in MacPorts and
 keeping it around only for the benefit of software that is not compatible
 with libressl. In that case the ports that are compatible with libressl
 should specify a dependency on `path:lib/libssl.dylib:libressl` (to
 continue to allow users to use libressl-devel instead if desired); their
 revisions should be increased so that they rebuild with the correct libssl
 library version and `install_name`; openssl should be changed to install
 into a different location (like ${prefix}/lib/openssl and
 ${prefix}/include/openssl as you suggested, or even just
 `--prefix=${prefix}/libexec/openssl`) so that it does not conflict with
 libressl; and the remaining ports that require openssl should change their
 dependencies to `port:openssl` and have their revisions bumped to find
 openssl in its new location (probably along with portfile changes to help
 them find openssl in the new location).

 Replying to [comment:3 jeremyhu]:
 > The same could apply to boringssl as well.

 I don't see a boringssl port in MacPorts yet. Is there some need it meets
 that libressl would not? I'd like to keep things simple, and simplest
 would be not to add another ssl library.

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