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

[Mojca Miklavec]

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

Mojca