Hi, I'm not sure if I understood the question, but here's my naive attempt to answer ...
On Thu, Jan 29, 2015 at 12:59 PM, René J.V. wrote: > > - Has a complementary feature (as in complementary colours) to the > replaced_by keyword ever been considered? A keyword that allows a port to > indicate that it's an alternative to another port? I'm not sure how invasive > the addition of such a keyword would be, nor how easy to implement for > someone who doesn't know MacPorts inner works (like me). Is this something to > request on trac? I'm not aware of one. The most reasonable solution I can think of given the current behaviour of MacPorts would be to define a metaport like qt5-meta with two conflicting variants (+with_alternative1 and +with_alternative2) where +with_alternative1 means dependency on qt5-variant1 and +with_alternative2 means dependency on qt5-variant2. Then any ports that can depend on either one or the other (and has no problem if qt5-variant1 gets replaced by qt5-variant2 at any time), that port could declare a dependency on qt5-meta. But you would still have to uninstall one port manually before being able to install the other port, so that wouldn't really be comfortable for users. In my opinion "alternative_to" would not be just a trivial addition. And it's not clear to me how to implement it properly to cover "all cases". And it's also not clear to me what exactly is it that you would like to achieve with that keyword. 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. They might work equally well with both, but they would install files to a different place or link to a different library depending on which one is installed. 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. Mojca _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
