I'd hope that there's a way to robustly move from one variant to the other
without the user having to engage with "port" to do so. I would hope that we
can avoid forcing the user to explicitly deactivate one and activate the other
variant.
I can think of a way to do this where we would end up with both variants for a
while during the transition ... the end result might be a bit confusing to
view/read when listing installed ports, but at least this way would avoid
forcing the user to do anything more than update outdated ports.
We can add a variant that depends on another variant. Thus, for example, if we
were moving from "+doc" to "+docs", we could do:
{{{
variant doc requires docs description "Deprecated variant; use 'docs' instead"
{}
variant docs description ... { [actual stuff to do for this variant] }
}}}
thus if the port currently has +doc enabled then doing this technique should
force +docs too. That said, this method would end up with "+doc +docs" for a
while, which isn't desirable.
I don't know if, after say 6 months, we then remove the deprecated "+doc"
whether any update will still contain the notation "+doc" or whether it would
be removed. One can test this out easily, of course.
I'm sure that some of the MacPorts main developers know better than me the
answers here. Hope this is useful! - MLD
On Sun, Apr 14, 2019, at 3:17 PM, Richard L. Hamilton wrote:
> How would that work with regard to "port upgrade" of installed ports?
> Would (for those ports presently using the one chosen to be changed)
> both be accepted for compatibility? Or some other magic? Or would
> people end up having to explicitly deactivate the installed one, and
> install the new version with suitably altered variant(s) requested?
>
> Seems to me the latter would be a nuisance best avoided.
