[MacPorts] #54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc. (was: coexistence of libress, libressl-devel, openssl, boringssl, etc.)
MacPorts
noreply at macports.org
Thu Jan 11 12:58:02 UTC 2018
#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
More information about the macports-tickets
mailing list