about alternative ports and the build bots

[René J.V. Bertin]

On Tuesday September 29 2015 01:32:13 Ryan Schmidt wrote:

>path:-style dependencies are for ports that are drop-in replacements for one another. You've given a prerequisite for this scenario that the ports you're talking about are *not* drop-in replacements for one another. Therefore you can't use path:-style dependencies, and should instead use conflicting variants, with one being default. The default one will be built by the buildbot builders; if the user uses the other variant, that won't match the signature of the binary so they'll build from source.

I was going to write that that's not satisfactory, but it is in fact besides the point (and so would pointing out that it's not my choice (not to say fault) that we're in the current situation O:-)).
Path-style dependencies aren't actually being used to depend on one or the other port I also very specifically want both ports to act as drop-in replacements when building. A user who opts for the one port should be able to install any dependent port that doesn't have conflicting requirements without depending on the goodwill of the port maintainer to provide a variant allowing to do so. And preferably without having to remember the proper variant each time s/he installs a new dependent port, esp. since this should be possible.

Of course I have already introduced a variant that gets set when one of the 2 ports is installed. The only thing that's held me back from doing the same with the other port (rather, PortGroup) is that I no longer feel much desire to help maintaining it, let alone do test-builds (not with something as humongous as Qt5). Though nothing would stop me from putting the variant stuff in the "header" PortGroup, before it loads the actual payload that corresponds to the preferred OR the current situation.

Re: path-style dependencies, did I really state or imply they were being used to depend on either of the installed ports? I'd hope not, not with the bit of code I copied from the header PortGroup. To stick with the generic example, it's that header, "foo" PortGroup that takes care of pulling in the appropriate dependency by loading either the foo-mac or the foo-xdg PortGroup. Each of those PortGroups could then use path-style dependencies if there are also foo-mac-devel and/or foo-xdg-devel ports (I actually do have a qt5-kde-devel port, and even gave some love to my old qt5-mac-devel port for a user who needed a recent Qt5 build on OS X 10.6).

R