<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jul 22, 2014, at 11:37 AM, Daniel J. Luke <<a href="mailto:dluke@geeklair.net">dluke@geeklair.net</a>> wrote:<br><br><blockquote type="cite">So here's my short proposal:<br><br>1. switch the perl5 port to actually install perl5.20.x<br>2. deprecate and remove the other perl5.x ports<br>3. change the perl5 portgroup to just build/install p5 ports that work with whatever we install as perl5 (currently 5.20.x)<br>4. Update other ports to depend on the p5- module(s) and the perl5 port<br>5. Make some way to (easily) force rebuilds of all p5 ports when there's a new release of perl5.x.y (probably on both new .x.0 and .x.y releases)<br>* one thing I thought might work would be to [ab]use epoch by setting it to the YYYYMMDD of the perl5 release in the perl5 portgroup (so individual ports can still update it to a newer epoch if needed, and we can keep bumping it for every perl5 version). I haven't though about it too much or tested it yet, though.<br></blockquote><br>While I’m all for getting perl 5.20 up to speed on Macports, I’m against removing perl 5.16 or perl 5.18. I have been testing a number of p5 ports with perl 5.18 and only 1 of them failed to build for me. But it is an important one. The port is p5(.18)-pdl and it is needed for the demeter/demeter-devel ports. Given that we cannot yet build any p5.20 ports, I think it is way too early to be switching to it by default. Much less the only option. So I vote we at least keep perl 5.16 and perl 5.18 and all of their modules around for a while. <br><br><br>Cheers!<br>Frank<div><br></div></body></html>