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

[René J.V. Bertin]

On Friday December 30 2016 17:25:20 Mojca Miklavec wrote:
> I would agree that it would be helpful to have some "more advanced"
> version of dependency specification available.

The depspec syntax doesn't necessarily have to be more complicated. Ports that require more advanced functionality could also write wrappers around depends_lib and family, like what we're discussing for Qt5 for instance. Basically,

depends_lib-append path:/some/representative/file:${depName}

> 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

If many ports depend on nodejs a PortGroup can be provided. I could define an array mapping os.major to a nodejs version, and then you can simply do

depends_run path:bin/node:${nodejsPortFor(${os.major})}


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

You seem to be describing what I currently have implemented for qt5-kde ...! :)
With the clarification that my implementation indeed only defines the variant when qt5-kde's PortGroup is used, which a priori should only happen when that port is being used.

Do you have an idea for that "more advanced functionality to achieve that" adding a variant?
We could consider using 2 variants, even if that would be redundant. What I could think of is a procedure, defined in a PortGroup, that would be called with the name of the main/base/standard port (as far as there's one) and a list of the alternative ports; this procedure could then declare variants corresponding to each of the alternatives. Going much beyond that is probably going to be complicated because so likely to be (very) port-specific. 

Thinking aload there's one thing that could help here is a possibility to unset a variant in a Portfile if that variant comes from variants.conf . This would allow the selection mechanism to be based on the variant with more flexibility. That is, on a virgin system the user could do `port install foo` with "libressl" in his sources.conf and all SSL dependencies would come from a newly installed LibreSSL. The user could still have the possibility to replace LibreSSL with OpenSSL without getting errors or other unexpected behaviour I don't really foresee now.
Sounds a bit far-fetched re-reading this, but I'm sure I had a good argument yesterday .. :-/

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

What I meant with the remark about choice is that using port:qt55 could be unavoidable on 10.7 (so there's no point in forcing users to set +qt55 there), and similarly you make the choice to use port:qt5-kde once when you decide you want full-featured KF5 applications. There too there is little point to confirm this choice by having to set +qt5kde explicitly for each new KF5 port you install. It would be a bit different if a KF5 port could put up a question "you have qt5-kde installed, are you sure you want to build without +qtkde5?".
You *could* instruct users to set such a variant in variants.conf, but I find even that a bit of an unnecessary complication.

> security safeguards) to add support for building variants on the
> buildbot like "gtk +quartz". What we haven't yet agreed on (or are not

Off-topic, but I hope that's about GTk3. GTk2's Quartz implementation was never superb as far as I can remember.

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

?

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

Yes, that has bitten me more than once.

There's also the fact that +universal tends to be infectious, and you end up doing installs from source that are twice as expensive as they could be. All it takes to catch this particular ailment is to install the 32bit Wine port ...

R.