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

[David Evans]

On 8/12/14 9:30 AM, Frank Schima wrote:
> 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
>

Sounds good to me.  If we can agree on this, then maybe we can move on and
make some progress.  Otherwise, 5.22 may be out before we make a
decision 

Dave