Port variants for deps

[Ryan Schmidt]

On Sep 15, 2019, at 22:31, Eric F (iEFdev) wrote:

> What would be better (ie good “portiqette”)… 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.

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.