Perl changes (+ please wait a bit with commits in perl modules if possible)

[Daniel J. Luke]

On Aug 12, 2014, at 5:25 PM, Dan Ports <dports at macports.org> wrote:
> 
> On Tue, Aug 12, 2014 at 08:19:27AM -0700, David Evans wrote:
>> As Daniel has said, no point in changing things that are going to go away so
>> we need to get a consensus on where we want to go with this.  My input here
>> would be this:
>> 
>> *  make the necessary changes to perl5.18 to work as perl5.20 does
>> *  leave perl5.16 and lower alone for now
>> *  update ports to support p5.18 & 5.20 unless there is strong sentiment
>> to go to 5.20 ASAP.
>>   not much difference in adding one or two new branches
>> *  then decided which branches to remove, go to single perl (which has
>> other consequences), etc.
> 
> This makes sense to me. I don't know enough about perl to comment
> usefully on the subrelease path issue, so I'll leave that to people who
> actually know what they're talking about.

it probably doesn't hurt anything (and does maybe make things slightly easier). I would prefer that we patch the upstream perl as little as possible, though.

[we could continue working around the issue by just revbumping all the p5 ports when we upgrade our one true perl5 and possibly eventually enhance macports so that a port can indicate that its dependencies need to be rebuilt]

> I think it is worth adding support for p5.18 and 5.20 to the current
> p5 ports since that doesn't seem terribly onerous -- especially if
> Mojca has already written a patch :). And it'll give us a chance to see
> if any of the existing perl modules have trouble building for
> 5.18/5.20.
> 
> Longer-term, we need to decide whether to go to a single perl.
> Personally, I'm in favor of this. But it's clearly going to involve a
> lot of work (even if it'll save us more in the long run) so we
> shouldn't let that stop us from doing this now.

I don't think it's really any more work than what is going on now. The hardest thing will be trying to make the transition work well for people (and maybe we just can't make it nice? - changes to default perl5 are already not picked up by installs, so people have to do manual work to get their install using a newer perl5).

A reasonable interim goal state would be:
1. perl5 port installs the current perl5 (which is 5.20.0 right now)
2. p5 ports install like they used to (perl5 portgroup doesn't make versioned p5.xx modules anymore)
3. ports depend on p5-xxx or the perl5 port

To me, it makes sense to figure out a plan on how we get to that state, and not spend a lot of time making keeping the currently broken situation mostly working.

As we often have things that don't quite work, I'm not opposed to having a lot of things broken (on a branch, probably) while this is being worked on/figured out. It would probably be helpful to write up an automated procedure to run through all of the testsuites for the perl module ports.

Once we've simplified things (one perl, one set of perl module ports) - then we can more sanely try to tackle the other things we need to do in order to make MacPorts perl more useful.

--
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.          |                          
+========================================================+