subport and keyword questions/suggestions

[Mojca Miklavec]

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