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

[Mojca Miklavec]

On Tue, Aug 12, 2014 at 11:25 PM, Dan Ports 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.
>
> 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 :).

I committed that initial patch. Let's give it a few hours to complete ;)

I only revbumped and upgraded the ports that already had support for
5.18, but upgrading the rest (without testing) can boil down to
writing a smart regular expression. The question is whether we also
want to clean up, upgrade and/or test the rest as we go (which is what
I did [without extensive testing] to the ports I committed now). I'm
willing to automatically add 5.18/5.20 to the modules. But that still
leaves us with the need to test.

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

But it will only save work if we approach this properly. If we would
simply decide to use a single perl *now*, we would still need to
modify all the > 1000 ports and there would be no easy workaround for
broken modules (like p5-wx etc.). So without some extra work and as
things stand now, support for a single Perl version wouldn't really
solve anything.

My preference would be to keep support for the latest two or three
perl versions (though I'm not strictly opposed to a single version),
but fix the rest in such a way that "sudo port upgrade outdated" would
upgrade from 5.20 to 5.22 for *all* modules and dependents
automatically. And so that users could potentially switch between
different versions without the need to manually reinstall zillions of
ports. Currently there's a big problem because once "portname
+perl5_12" is chosen in a bunch of ports, there is no easy way to
globally switch to "portname +perl5_20". If we solve the problem of
"difficult to upgrade in a sane way", then the rest would be a lot
easier. It would also be nice to be able to test Perl 5.21.

I plan to open a ticket discussing different approaches for the future
(unless someone does it before I get to it).

Mojca