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.