Hi, I'm coming back to this discussion because of something that came up elsewhere.
I think we had a consensus a while back that the implementation of the support for using libressl at user discretion left a bit to desire. There could be a protection against installing binary packages built against OpenSSL if you have LibreSSL installed using existing mechanisms, using what I'd call an autodefault variant (a PortGroup that adds the proper SSL depspec and does `default_variants +libressl` when port:libressl is detected). The situation with LibreSSL vs. OpenSSL is still relatively simple in that both are single ports. Suppose this were not the case but both ports had subports providing specific optional components that ports could depend on: So: libressl, libressl-opt1, libressl-opt2 openssl, openssl-opt1, openssl-opt2 with proper conflict declarations. For simplicity, let's assume a port:foo that requires both optional components, properly declared with path-style depspecs. Let's also assume that some protection is in place against installing the wrong binary builds, say an autodefault +libressl variant: %> port deps foo # for port:foo openssl openssl-opt1 openssl-opt2 Now what should happen when a user has LibreSSL installed, but not yet (all) of the components? Even with path-style depspecs, `port install foo` will try to pull in openssl-opt1 and/or openssl-opt2, which it can't (and shouldn't) because they conflict with port:libressl. The only way I see to make this work automatically is to have adaptive depspecs, so that on a system with LibreSSL as the SSL provider you get %> port deps foo # for port:foo +libressl libressl libressl-opt1 libressl-opt2 I guess this may raise a few eye-browes because there probably is no precedent for this yet. But isn't it exactly what should happen, and isn't it also what a user you'd expect to see after deciding that you want to use LibreSSL instead of OpenSSL (or vice versa)? I've used the LibreSSL vs. OpenSSL example once more because it's the closest existing example of a situation that we're going to have with Qt5. I know this resembles the situation around PythonX.Y and Perl5.Z, but there's one crucial difference. Those are variants and subports that for the vast majority can co-exist because different Perl and Python versions can co-exist. Not so with LibreSSL/OpenSSL, and not so with Qt 5.5, Qt 5.6, Qt5-kde etc. Those are and will be ports that be mutually exclusive and for now the consensus among the concerned port maintainers is that we want to avoid imposing variants as much as possible. Because those variants would in fact confirm time and time again a choice that is no longer a choice (and never really was one). Sorry, this has again become longer than I intended. R.
