Perl changes (+ please wait a bit with commits in perl modules if possible)

[Frank Schima]

On Aug 12, 2014, at 10:03 AM, Mojca Miklavec <mojca at macports.org> wrote:

> On Tue, Aug 12, 2014 at 5:23 PM, Ryan Schmidt wrote:
>>> On Aug 12, 2014, at 10:20 AM, David Evans wrote:
>>> On 8/12/14 8:06 AM, Ryan Schmidt wrote:
>>>> On Aug 12, 2014, at 9:56 AM, Mojca Miklavec wrote:
>>>>> Now about 5.8-5.16: my idea was to initially set the INC path for
>>>>> those versions in such a way that it would include
>>>>> "5.16.3/darwin-thread-multi-2level 5.16.3
>>>>> 5.16.1/darwin-thread-multi-2level 5.16.1
>>>>> 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
>>>>> <something>/5.16/<something> without the subrelease. That means that
>>>>> there would initially be no urgent need to revbump all the > 1000
>>>>> ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
>>>>> would make sure to revbump all p5.18-foo ports.)
>>>>> 
>>>>> But I'm unable to figure out how to patch Perl to do that. The INC
>>>>> path additions seem to be ignored.
>>>> Why handle <= 5.16 differently than >= 5.18?
> 
> Because for >= 5.18 everything will work out-of-the-box once I apply a
> huge patch (cca 300 revbumps or updates). It will work automatically
> on ports where we add 5.18/5.20 later.
> 
> For <= 5.16 see below.
> 
>>> Because we want them to go away? Or is the effort to do them all
>>> relatively trivial?
>> 
>> My assumption was that since a patch is already in place for perl5.20 and perl5.18 it could be backported to earlier versions with minimal effort,
> 
> We can either clean up the INC path entirely (the same way as it's
> done in 5.18 and 5.20), but then need to also revbump the remaining >
> 700 modules (which needs to be done at some point anyway, if nothing
> else because we'll have to add 5.18 and 5.20 and also because half of
> those modules needs an update). But then this would have to be done
> "at once".
> 
> My idea of a relatively trivial fix was to change the path where
> perl5.16 installs files, so that perl would keep looking at the old
> locations. It turned out that the patch wasn't exactly as trivial as I
> thought it would be. And I'm not yet sure why. But I bet that the
> patch isn't that complicated either. It might be one-liner once we
> figure out what and where to fix. See
>    https://trac.macports.org/ticket/43480#comment:10
> 
> Anyone willing to help me out is invited to check what exactly is
> wrong with the patch I proposed.
> 
> 
> So it's probably still easy to do, but not as trivial as I hoped it to be.
> 
> Other reasons for handling perl5.16 differently include:
> 
> - most likely there will be no perl 5.16.4 (and most certainly no perl
> 5.14.5, 5.12.6, ...), so we probably don't need to care about
> locations of modules and libraries changing in the future
> 
> - once we complete support for 5.18 and 5.20, implement something like
> "5.10-foo replaced_by 5.20-foo" and switch dependencies from p5.12-foo
> to p5.20-foo, we could theoretically drop support for older perls; we
> keep 5.12 around just because lots of ports depend on it (but don't
> really need to depend on it)
> 
> - versions <= 5.16 are no longer supported upstream
> 
> - my patch to drop the subrelease number is not really supported
> upstream and has not been tested too extensively; it might be that
> some obscure module actually depends on the fact that the module path
> should contain three numbers; so if p5.16-foo would keep working and
> p5.18-foo not, you could point your fingers at that patch ;)
> 
>> and that since Mojca plans a revbump of all perl modules anyway, before that mass revbumping would be the ideal time to do that.
> 
> Yes. The ideal time would be now. That is: if we want to do it at all.
> But patching <= 5.16 apparently means either adjusting the patch a bit
> or revbumping also the other > 700 ports at the same time (which could
> be automated).

I see no reason to change perl 5.16 or lower because they are already working. Let’s just look forward to 5.18 and 5.20. Even if 5.18 is a lame duck already. 

For me, the only thing holding up moving to perl 5.20 is p5.20-pdo, 5.20-wx and possibly a few others that work fine with p5.16. 


Cheers!
Frank