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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev