Port variants for deps

[Eric F (iEFdev)]

On 9/20/19 3:10 , Ryan Schmidt wrote:
> 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.
I wanted to see how the Perl subports were made, so I looked int the portgroup
and found a usable function to work with. No, prob not the best way, more than
it worked. /(Since the perl2{6,8} are subports already - technicallly, they
became: “sub-subports”. :))/

> 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.
> “What do you expect them to do?”

Well, here's the idea I had (still have)...

MariaDB ships with a newer/better version of “mytop” (»»»
<https://github.com/MariaDB/server/blob/10.5/scripts/mytop.sh>, 2012), compared
to the standard mytop (»»»
<https://metacpan.org/source/JZAWODNY/mytop-1.2/mytop>, from 2002). Quite a lot
of changes and improvements.
Since it's comes bundled with the mariadb install, I thought it would be nice to
make it work out of the box. It wouldn't take much to do it:
 - Reinplace the “shebang”,
 - add a sample config file,
 - and add 2 dependencies (to get the 3).

But, since things are as they are now. If that was added, one would need to
install (example) mariadb-10.2 with: /`port install mariadb-10.2 +mariadb10_2`/
- which doesn't feel ok (or look good), for something that was supposed to work
out of the box. That's why I wanted to have the dependecy picking up the variant
automatically. It would be really nice to make it work right away.

I guess I could make a port that is fixing that instead - were ppl have to
choose a specific variant (and/or with the help of that variant port group Dave
mentioned). Or make a /“mariatop”/ separately, to avoid name confilicts. I don't
know. I'm still bouncing the ideas. But, that was the idea.

> 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.
Yes, I understand that, and why it got closed. But, even though the name/term is
“subport”, they were kind of not subports… They were more acting as a
/“translation layer”,/ and not real ports - just matching the variant. Anyway, I
thought it was a smart simple way, with minimal xtra code added to solve it.

To go back to earlier discussion… Even if the PR was closed (and I don't expect
it to get reopened again), I finished it with an example of separate
(sub-)subports and variands. Just wanted to finish it, exapand the idea, and see
where [the code] took me. »»»
<https://gist.github.com/iEFdev/a8495a2494939bc52261a5797d110057#file-portfile-L29-L66>
/(I'll remove that one later)/.

Not too much xtra code, but it'll get cluttered …and then all those conflicts,
that are not supposed to conflict. :) But, that was based on that about making
subports, and remove the variant later on.


I'll look into the other ideas instead - or, any suggestions…?

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