port:libressl vs port:openssl, path-style variants and prebuilt binaries

[Mojca Miklavec]

On 30 December 2016 at 11:32, René J.V. Bertin wrote:
> 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.

I agree here.

> There could be a protection against installing binary packages built against OpenSSL if you have LibreSSL installed

That would be nice.

> 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 would agree that it would be helpful to have some "more advanced"
version of dependency specification available.

Another case that just popped up recently. Some ports require nodejs
and don't care which one is used. Different versions of nodejs
conflict with each other, nodejs6 does not build on 10.6 any longer,
some days ago it did not even build on 10.7.

One may use:

depends_run bin:node:nodejs6
platform darwin {
    if {${os.major} < 12} {
        depends_run-replace bin:node:nodejs6 bin:node:nodejs4
    }
}

but I hate the idea of having to do this in every single port that
depends on nodejs and then change all those ports when a bugfix pops
up that fixes a build on 10.7. Luckily in this case I don't think that
replacing nodejs has any influence whatsoever (there is no
"ABI-incompatibility" involved).

> 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 like the idea of having a mechanism that would automatically pick
    libressl libressl-opt1 libressl-opt2
based on <something>. That something could include whether the user
has libressl installed. But I would also support the idea of
automatically adding a variant "+libressl" to that port. (We might
need a bit of more advanced functionality to achieve that in a proper
way.)

> 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).

I'm not sure about that. I see your concern that variants are causing
lots of headaches. Yes, they do. But the situation could be improved a
lot by implementing some additional functionality in the core and on
the buildbot.

For example it is currently straightforward (four lines of code in
buildbot's master.cfg to add functionality; plus some additional
security safeguards) to add support for building variants on the
buildbot like "gtk +quartz". What we haven't yet agreed on (or are not
yet sure about) is:
- whether to allow developers to specify any variants manually when
doing forced builds
- how to implement automatic detection of additional variants that
need to be built.
- how to handle dependencies properly (if one would build "gtk
+quartz", dependencies will be compiled with "+quartz" as well, but
when a dependency is updated, the buildbot might forget to add
"+quartz" to that dependency).

The other front is that once the dependency solver gets completed, the
variants should start working automatically.

And we would need some more functionality to facilitate changing a
variant over a large number of ports at the same time (at the moment
it's nearly impossible). Say, to revert from 5.7 back to 5.6 if
something breaks. And some functionality to automatically change from
+qt56 to +qt57 on the latest macOS version when Qt gets upgraded.

Currently it's also a pain when the default variant changes from say
+gcc5 to +gcc6, users simply stop getting binary updates because the
old variants stick forever. We need to start tracking when a variant
was explicitly requested.

https://trac.macports.org/ticket/46956

Mojca