Port variants for deps

[Eric F (iEFdev)]

On 9/16/19 23:20 , Ryan Schmidt wrote:
> On Sep 15, 2019, at 22:31, Eric F (iEFdev) wrote:
>> What would be better (ie good “portiquette”)… Adding subports (keeping the variants), or replacing variants with subports?
> Provide only one way for a user to install a feature. Convert variants to subports, if appropriate.
Thanks Ryan! Yes, I guess that's the best way, and cleaner.

> Usually if a variant changes names we keep a compatibility variant around for a time. For example, if a port provided a variant X which a user may have installed, and then we change the variant name to Y, we keep a variant X that's marked as requiring variant Y. When the user upgrades their installation, they will automatically get the new variant Y (and the old variant X which now does nothing). After a sufficient period of time to allow all users to have upgraded (we usually recommend one year), the old variant X can be removed.
>
> Converting variants to subports may or may not allow that same easy upgrade path to take place. For example, if the new subport has a dependency on the main port, you cannot make the old variant depend on the new subport, because that would introduce a circular dependency. One possibility in that case is to leave a compatibility variant for a time that does nothing but print an error message telling the user to install the subport.
I made a PR yesterday »» <https://github.com/macports/macports-ports/pull/5284>,
and that was what I had i mind. It will work both ways - as subports, but still
be able to use it the same way as before (didn't want to break anything). And if
the variants have to go (later), one could put everything in a switch later, or
something like that.

If that approach is ok, perhaps I should add an err-msg like that to it? Err, or
note?

· Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190917/a7bb6231/attachment.html>