Port variants for deps

[Ryan Schmidt]

On Sep 16, 2019, at 17:01, Eric F (iEFdev) wrote:

> 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 »», 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?


Oh, I didn't realize you were talking about a perl module. That's more complicated, because a perl module port already creates its own subports, one for each perl version. I see you've figured out a way to do it anyway, but I'm really not sure it's advisable. There are other ports that depend on p5-dbd-mysql. What do you expect them to do? Do you expect each and every one of them to add variants for each version of mysql/mariadb, and in those variants choose the matching new subport of p5-dbd-mysql?

In the case of ports that use mysql/mariadb, the idea was that the user should be in control of what version of mysql/mariadb is used. The user can specify their choice globally in variants.conf and then it applies to any port offering those variants. It should not be up to other ports to make that decision for the user.

And you've noticed that each of your proposed subports would conflict with each other. Subports aren't supposed to conflict. They're supposed to be installable at the same time, because they're supposed to represent things a user might want to install at the same time. That doesn't fit this scenario, where variants are probably the best solution, as Dave mentioned in the PR when he closed it.

Subports are great for optional features that can be built later. For example, optional documentation for a program -- a user doesn't want to have to recompile the program just to install its documentation. Or consider graphviz: it has a main port for the command line programs and libraries, and subports for the optional macOS and Qt GUIs. Or nginx: its many variants should be converted to subports so that those modules can be built each by themselves when they're needed without having to recompile nginx itself. (My understanding is that Clemens wanted to do this but that nginx's plugin/module support wasn't yet good enough to do it, or maybe the various plugins/modules hadn't adapted to the new way to do it, but that was a few years ago so maybe the situation has improved since then and the conversion to subports could now be done.) The php port's many subports are another (way too complicated) example.