changing default perl

Daniel J. Luke dluke at
Mon Nov 4 06:58:16 PST 2013

On Nov 3, 2013, at 5:44 PM, Clemens Lang <cal at> 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
> that?

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 ----------------* |                          
| *-------------- -------------* |                          
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          

More information about the macports-users mailing list