Mojca Miklavec mojca at
Wed Jul 23 08:20:23 PDT 2014

On Wed, Jul 23, 2014 at 4:11 PM, Daniel J. Luke wrote:
> On Jul 22, 2014, at 5:59 PM, Mojca Miklavec wrote:
>> But both what you said and what I wrote requires some work and
>> testing. And cannot be the answer to "we urgently need to allow 5.20".
> that's why it was under 'longer term' ;-)
> thoughts on 1-5?

Just that you'll have a lot of work to do and I would expect a lot of
problems for a week or two ... and I'm not sure if it pays off to do
that huge amount of work.

My suggestion would be to concentrate the effort into getting it done
right (with some CPAN integration) and try to achieve usability with
the least amount of work that still leads us to the desired effect.

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

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

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).

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.

But that's just my opinion. I don't insist that it's the best possible
solution, it's just some brainstorming.

More information about the macports-dev mailing list