perl (again)

Daniel J. Luke dluke at geeklair.net
Tue Jun 10 10:46:20 PDT 2014


On Jun 10, 2014, at 1:20 PM, Frank Schima <mf2k at macports.org> wrote:
> 
> On Jun 8, 2014, at 8:26 PM, Daniel J. Luke <dluke at geeklair.net> wrote:
>> so, perl5.20 is out (and the new/current latest stable version)...
>> 
>> any chance we can get a little less crazy and just ship the 'current' perl (instead of being perpetually behind)?
> 
> The current issues are:
> 
> 1. We need a perl5.20 port. Difficulty: ? 
> 
> It would be really nice if the perl5.X ports could be merged into a single Portfile with subports so that new perl versions would be relatively easy to add. All of the current perl ports seem to be different enough that I don’t understand what is required for perl5.20. 

perl builds easily (without patches) on Mac OS X. It looks like the perl5.18 port would probably work easily for perl5.20 (I haven't tested it yet, though).

> 2. The perl5 and intltool ports need a perl5_20 variant added. Difficulty: Easy 
> 
> 3. All of the p5-* ports need to be updated to add 5.20 to the perl5.branches line. Difficulty: Hard

I think that all of the support for multiple perl versions should really just go away. While it was a worthwhile goal, there just aren't enough people willing to do the work to make it work the way we've designed it.

We should ship one perl (the latest stable release) - and ship that as the perl5 port, and have all of the p5 ports build with it (we may need/want to revbump them all whenever we switch to a new major perl release).

If (and only if) there is some reason to keep an older perl around, whomever needs it can make a separate port for it (and I would say a separate set of ports for any modules that were needed as well).

> We have barely made a dent adding p5.18 subports. It would be much better if the perl5 portgroup simply always added p5-* subports up to 5.20. Individual portfiles could override that if some perl versions do not work. Checking and adding p5.20 to each p5-* port seems like an insurmountable goal, certainly in the short-term. The only way to do that would be to globally add it to every p5-* port without testing. At that point, we should simply add it to the perl5 portgroup. Given that all p5-* Portfiles have the perl5.branches line, I think it should be removed from all of them globally. But then we have the issue of notifying maintainers first. Having the perl5 portgroup add new perl versions seems to me to be the only way we are ever going to stay current with perl versions. 

it used to work that way, but I believe it was changed because existing p5 ports wouldn't necessarily have been tested against the newer perl release...

> The biggest thing we have going for us is that most of the perl ports are not maintained. At the same time, no one is doing much about the perl issue in Macports and that’s why it is behind the current version. 

Personally, I gave up on using Macports perl as my 'main' perl a while ago (in favor of perlbrew) [mainly so I can keep up to date with a current perl and also because the p5 ports in Macports are often out of date as well].

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





More information about the macports-dev mailing list