<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#333333">
On 9/20/19 3:10 , Ryan Schmidt wrote:<br>
<blockquote
cite="mid:237906C1-B57E-4022-A86B-30A4582DDBDF@macports.org"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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. <i>(Since the perl2{6,8} are
subports already - technicallly, they became: “sub-subports”. :))</i><br>
<br>
<blockquote
cite="mid:237906C1-B57E-4022-A86B-30A4582DDBDF@macports.org"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
> “What do you expect them to do?”<br>
<br>
Well, here's the idea I had (still have)...<br>
<br>
MariaDB ships with a newer/better version of “mytop” (<a
href="https://github.com/MariaDB/server/blob/10.5/scripts/mytop.sh">»»»</a>,
2012), compared to the standard mytop (<a
href="https://metacpan.org/source/JZAWODNY/mytop-1.2/mytop">»»»</a>,
from 2002). Quite a lot of changes and improvements.<br>
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:<br>
- Reinplace the “shebang”,<br>
- add a sample config file,<br>
- and add 2 dependencies (to get the 3).<br>
<br>
But, since things are as they are now. If that was added, one would
need to install (example) mariadb-10.2 with: <i>`port install
mariadb-10.2 +mariadb10_2`</i> - 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.<br>
<br>
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 <i>“mariatop”</i>
separately, to avoid name confilicts. I don't know. I'm still
bouncing the ideas. But, that was the idea.<br>
<br>
<blockquote
cite="mid:237906C1-B57E-4022-A86B-30A4582DDBDF@macports.org"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
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 <i>“translation layer”,</i> 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.<br>
<br>
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. <a
href="https://gist.github.com/iEFdev/a8495a2494939bc52261a5797d110057#file-portfile-L29-L66">»»»</a>
<i>(I'll remove that one later)</i>.<br>
<br>
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.<br>
<br>
<br>
I'll look into the other ideas instead - or, any suggestions…?<br>
<br>
· Eric<br>
</body>
</html>