perl5.20

[Mojca Miklavec]

On Tue, Jul 22, 2014 at 7:37 PM, Daniel J. Luke wrote:
> On Jul 22, 2014, at 11:51 AM, Mojca Miklavec 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?

How exactly? (That's not a rhetorical question.)

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

Yes, rev-upgrade would fix it. (But we never know which ports to revbump.)

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

That needs more thinking. It would be certainly useful to have more
tests, but I'm not sure what exactly.

>> - 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/ ?

Yes, I'm sorry. (Even though python is facing similar "problems" as
perl with zillions of versions, only in a waaaay less problematic
way.)

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

I think that we should maintain a database of all perl modules in a
single file and semi-auto-update that file from CPAN on regular basis.
Only non-standard settings could then be replaced in individual
Portfiles and for most ports we wouldn't even need a Portfile.

But both what you said and what I wrote requires some work and
testing. And cannot be the answer to "we urgently need to allow 5.20".


I'm currently committing a bunch of changes in perl modules that I
have "on stack". Once I'm over the list, I'll look into Perl 5.20 to
see if I can fix the problem with a trivial change.

Mojca