port:openssl dependency

[René J.V. Bertin]

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.