perl5.20

[Daniel J. Luke]

On Jul 22, 2014, at 11:51 AM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> On Jul 19, 2014 1:15 AM, "David Evans" wrote:
> > On 7/18/14 3:47 PM, Mojca Miklavec wrote:
> > Well, I'm sorry but I don't really see the need for these experiments.
> 
> At the moment it is very inconvenient to upgrade perl from 5.x.y to 5.x.(y+1). A bunch of "random" ports become broken "just because" (because they link against perl and location of a fully compatible libperl.dylib changes for no good reason).

maybe we should symlink libperl.dylib to somewhere stable?

(and/or won't rev-upgrade just fix these when upgrading perl? if it doesn't, can we just make it fix them?)

> - I'm unable to test 1000 ports.

we should probably enhance `port test` to be more useful. With the perl modules (at least), they usually have test suites that we should be able to run to verify we're not breaking things - so changes to MacPorts perl could get some tests 'for free'

> - I'm willing to test a bunch of ports, but once we add p5.20 it will be very time consuming and a lot of mess to change things in *all* python modules.

s/python/perl/ ?

we should really just fix our multiple-perl problems by pushing one perl5 (the latest perl5 release from upstream) and shipping one set of p5-modules (that build against the latest upstream perl5 release)

> - I'm almost sure that hardly anyone will be willing to do any considerable amount of testing, so it will boil down to max 5 people testing at the end anyway and most bugs would surface later.

which has actually been the case for most of MacPorts for most of its life anyway, so it's not really a problem ;-) [or at least, not a new one]

> - There are plans to change the way how Perl and Perl modules are written and installed, but we should continue updating ports until then. However spending an enormous amount of time changing and fixing a large number of ports would be almost a wasted effort (given that most of the work done now will be thrown away anyway).
> > But I do point out that perl 5.20 is the current stable release
> And we didn't even port any noticable amount of ports to 5.18, let alone make 5.18 the default perl version.

So here's my short proposal:

1. switch the perl5 port to actually install perl5.20.x
2. deprecate and remove the other perl5.x ports
3. change the perl5 portgroup to just build/install p5 ports that work with whatever we install as perl5 (currently 5.20.x)
4. Update other ports to depend on the p5- module(s) and the perl5 port
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)
* 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.

longer term:
6. better CPAN integration (get module list from CPAN, build using something like cpanm, install our own cpanm that installs the appropriate port, etc.). There are too many modules that update too frequently for the current level of contributors to provide well-tested and updated ports of the individual CPAN packages.   

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