[MacPorts] #46844: help2man: add support for perl5.{16,18,20}

Mark Anderson emer at emer.net
Sun Feb 15 12:15:34 PST 2015


Yeah. I think bumping it to 5.20 is the best idea, as we slowly move toward
toward the goal of One Perl to Rule Them All. Or whatever we wind up doing.

—Mark
_______________________
Mark E. Anderson <emer at emer.net>

On Sun, Feb 15, 2015 at 1:34 PM, Mojca Miklavec <mojca at macports.org> wrote:

> On Sat, Feb 14, 2015 at 5:07 AM, Ryan Schmidt wrote:
> > I also wouldn't have a problem with individual ports like help2man
> moving to newer perl versions like 5.20. I don't feel that we need to wait
> and try to do every single port at once, as that's likely to either not
> happen because of the amount of work involved or to introduce problems
> because of insufficient testing.
>
> It would actually be really nice if someone would volunteer to create
> a new ticket like this one:
>     http://trac.macports.org/ticket/44405
> to replace 5.16 with 5.20 and if we start the transition towards 5.20
> (optimally before they release 5.22).
>
> Being able to pick perl5_20 allows one to "get rid of" perl 5.16 and
> allows for some more testing, but if 5.20 is supported out of the box,
> there might be no need to offer the choice.
>
> I like variants, but I hate one specific aspect of them: when user
> installs one variant by default (for example +perl5_16) and when the
> default shifts to, say, +perl5_20, the user's choice remains at the
> old value (for no good reason) and the user no longer gets binary
> archives. I usually experience this "problem" with +gcc4x or +clang3x.
>
> Mojca
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150215/eb8ace9a/attachment.html>


More information about the macports-dev mailing list