Frank Schima mf2k at
Wed Jul 23 15:26:24 PDT 2014

On Jul 23, 2014, at 9:20 AM, Mojca Miklavec <mojca at> wrote:

> One slightly easier step-by-step approach could be the following
> 1.) Replace
>    perl5.branches      5.14 5.16 5.18
> in all perl modules with
>    perl5.branches_blacklist 5.8 5.10 5.12
> or to remove branche_blacklist altogether if the module builds with
> all perl versions. When that blacklist isn't present (or empty) simply
> make the module work with all known perl versions (defined in the
> PortGroup).
> That would get us all the modules updated to 5.18 and 5.20 "almost for
> free" (that change should probably be scripted to cover all thousand
> ports).

FWIW, I prefer this approach. This allows us to move forward faster. 

> 2.) Fix important problems discovered during addition of 5.18 and 5.20.
> That would get us the point where 5.18 and 5.20 would be well
> supported without major headaches.
> 3.) Make sure that no p5.12 is hardcoded anywhere (the ticket that has
> recently been opened), maybe try to hardcode 5.20 instead of 5.16
> where it works (or add variants).

I was wondering if we could have a variable in base that is the default perl version. 

> 4.) Once all that is done, Perl 5.8, 5.10, 5.12 and 5.14 could easily
> be removed. But it would be nice to take care of automatic
> "replaced_by" somewhere in the PortGroup.


> 5.) Once the above is achieved and working well for about a month or
> more, we could in principle also remove 5.16 and 5.18. But that is not
> absolutely necessary. In any case it would be a lot easier and safer
> to do it stepwise than to simply jump to the 5.20 train and suffer
> headaches from all the intermediate problems.

As long as everything works in 5.20. So far I’m hitting a few bumps with p5.20-digest-sha1 [1] and p5.18-pdl not compiling. I can’t even try p5.20-pdl until p5.20-digest-sha1 is fixed. 


[1] <>

More information about the macports-dev mailing list