On Sunday February 15 2015 19:58:14 Mojca Miklavec wrote: Hi Mojca, > Example: perl5.16 and perl5.20 could be treated as "alternative_to" > and many applications that need Perl just as a runtime dependency > could happily use either one or the other. But for many ports it > *does* matter which one is installed.
I think the answer about what I have in mind is simply an equivalent to letting ports require a specific variant of a dependency. > > If your KDE app depends on qt5-mac[-devel]-kde (if qt5-mac is not > sufficient), then specifying something like "qt5-mac-kde > alternative_to qt5-mac" won't help you in any way. It would just mean > that users would be allowed to uninstall qt5-mac-kde, replace it with > qt5-mac ... and then your KDE app would happily stop working. No. If qt5-mac-kde provides (an alternative to) qt5-mac that doesn't mean that qt5-mac is an alternative to qt5-mac-kde. It just means that users can install qt5-mac-kde, and any application that declares a dependency on qt5-mac will see that dependency fulfilled (without doing a path: style dependency check). OTOH, it should be possible for 2 ports to declare themselves mutual alternatives, for instance between qt5-mac and qt5-mac-devel, but one could also envision such a relationship between Xorg and XFree. R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
