about alternative ports and the build bots

[Ryan Schmidt]

On Sep 28, 2015, at 8:59 AM, René J.V. Bertin wrote:

> In short, consider 2 ports that are supposed to be alternatives like port:foo and port:foo-devel, but that are different enough in where they install libraries that their binary forms are not drop-in replacements, and that cannot of course be installed concurrently. To keep this generic, let's assume there's a port:foo-mac which adheres to a Mac-inspired install layout and port:foo-xdg which adheres to a layout that's compatible with the ones used on Linux and other Unixes. Let's also assume that there as always been a foo PortGroup that takes care of defining variables for the various install locations, and that sets up a path: style dependency on port:foo (or one of its alternatives). This PortGroup has been split into foo-mac, foo-kde PortGroups and a general foo PortGroup that can include the appropriate foo "sub PortGroup" as a function of what the user has installed or a preference declared by a dependent port.

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.