changing default perl
Daniel J. Luke
dluke at geeklair.net
Mon Nov 4 06:58:16 PST 2013
On Nov 3, 2013, at 5:44 PM, Clemens Lang <cal at macports.org> wrote:
> To be honest, I don't know why we've ever diverged from this strategy.
> We're in a habit of shipping the latest and greatest version of software
> for most ports we have, sometimes even if breaks dependents (in which
> case we try to fix the dependents or get upstream to fix them for us).
> Maybe somebody who has seen the transition back then can comment on
because the maintainer wanted to do it (I think one performance regression in one perl release was also mentioned on the mailing list).
> We're in a similar situation for python (and will probably be for php,
> mysql, ...), where we still allow users to install versions that have
> run out of support (even security-related) years ago, but I fear that's
> another can of worms we can open when the perl situation is resolved and
> we've learned our share from doing so.
We should remove the non-upstream-supported stuff everywhere, I think it's actually an active dis-service to users to help install software that's not getting security updates...
> I'd advocate for keeping the subport magic, though – there *will* be a
> perl 6 sooner or later, and not throwing away that might simplify this
> transition a lot.
It's probably safer to think of perl6 as a separate language (you can't use current perl5 CPAN modules in perl6).
Daniel J. Luke
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
More information about the macports-users