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
