On Wednesday January 10 2018 15:53:59 Daniel J. Luke wrote:
>is libressl now ABI compatible with openssl? IIRC some ports moved from path
>back to port style dependencies on openssl since libressl was only 'source'
>compatible and so if you have a path-style dependency and users get things
>from the buildbot (that were built against openssl) they get non-working ports
Last I heard it isn't, and wouldn't ever be because of technical and/or legal
issues (you'd have to use identical struct/class definitions taking you into
unclear waters re. licensing).
Do the SSL ports even use the same dylib versioning?
path-style depspecs would be possible, but you'd need to have a way to detect
which SSL port is installed and then set a variant, something like
if {[port_installed libressl]} {
variant libressl description {this port has been/will be built against
port:libresssl} {}
default_variants-append +libressl
}
Doing this in a PortGroup included by all ports depending on *SSL will make it
impossible to pull in an incompatible binary image from the build bots.
But if the ABI incompatibility remains there's little point in this kind of a
transparent approach; rather, it would make sense to support +libressl as a
global variant like +universal and require users to set it in variants.conf if
they wish to use libressl instead of openssl. A PortGroup or a new verb in
"base" could then be provided so that ports can declare that they depend on
either of the alternative *SSL ports, or if they're compatible with only a
specific implementation.
If all that's really worth the hassle...
R.
