<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#333333">
On 9/16/19 23:20 , Ryan Schmidt wrote:<br>
<blockquote
cite="mid:79ADC2A6-36DA-4EFD-A88E-25707E18F4D5@macports.org"
type="cite">
<pre wrap="">On Sep 15, 2019, at 22:31, Eric F (iEFdev) wrote:
</pre>
<blockquote type="cite">
<pre wrap="">What would be better (ie good “portiquette”)… Adding subports (keeping the variants), or replacing variants with subports?
</pre>
</blockquote>
<pre wrap="">
Provide only one way for a user to install a feature. Convert variants to subports, if appropriate.
</pre>
</blockquote>
Thanks Ryan! Yes, I guess that's the best way, and cleaner.<br>
<br>
<blockquote
cite="mid:79ADC2A6-36DA-4EFD-A88E-25707E18F4D5@macports.org"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
I made a PR yesterday <a
href="https://github.com/macports/macports-ports/pull/5284">»»</a>,
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.<br>
<br>
If that approach is ok, perhaps I should add an err-msg like that to
it? Err, or note?<br>
<br>
· Eric<br>
</body>
</html>