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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
