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.
