perl5.20

[Ryan Schmidt]

> On Jul 27, 2014, at 7:50 AM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> On Sun, Jul 27, 2014 at 2:20 PM, Ryan Schmidt wrote:
>>> On Jul 27, 2014, at 3:59 AM, Mojca Miklavec wrote:
>>> 
>>> On Thu, Jul 24, 2014 at 11:20 AM, Joshua Root wrote:
>>>> On 2014-7-24 01:20 , Mojca Miklavec wrote:
>>>>> One slightly easier step-by-step approach could be the following
>>>>> 
>>>>> 1.) Replace
>>>>>   perl5.branches      5.14 5.16 5.18
>>>>> in all perl modules with
>>>>>   perl5.branches_blacklist 5.8 5.10 5.12
>>>>> or to remove branche_blacklist altogether if the module builds with
>>>>> all perl versions. When that blacklist isn't present (or empty) simply
>>>>> make the module work with all known perl versions (defined in the
>>>>> PortGroup).
>>>> 
>>>> There's no need for an additional option and code for blacklisting. If
>>>> you want modules to opt out of perl versions rather than opting in, set
>>>> a default for perl5.branches in the portgroup, containing all the
>>>> versions. Then use perl5.branches-delete in portfiles to remove the perl
>>>> versions that they don't work with.
>>> 
>>> Like this?
>>> 
>>> 
>>> Index: _resources/port1.0/group/perl5-1.0.tcl
>>> ===================================================================
>>> --- _resources/port1.0/group/perl5-1.0.tcl    (revision 122703)
>>> +++ _resources/port1.0/group/perl5-1.0.tcl    (working copy)
>>> @@ -39,6 +39,7 @@
>>> # perl5.default_branch: the branch used when you request p5-foo
>>> options perl5.default_branch perl5.branches
>>> default perl5.default_branch {[perl5_get_default_branch]}
>>> +perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
>>> 
>>> proc perl5_get_default_branch {} {
>>>    global prefix perl5.branches
>>> Index: perl/p5-wx/Portfile
>>> ===================================================================
>>> --- perl/p5-wx/Portfile    (revision 122703)
>>> +++ perl/p5-wx/Portfile    (working copy)
>>> @@ -9,8 +9,8 @@
>>> # but earlier perl versions provide too old ParseXL versions and thus
>>> cannot be built
>>> # So 5.14 is the lowest version of Perl that used to work until recently
>>> # but is now broken as well: https://trac.macports.org/ticket/43157
>>> -#perl5.branches     5.8 5.10 5.12 5.14 5.16 5.18
>>> -perl5.branches      5.16 5.18 5.20
>>> +perl5.branches-delete \
>>> +                    5.8 5.10 5.12 5.14
>>> perl5.setup         Wx 0.9923
>>> revision            1
>>> 
>>> 
>>> Is it perfectly safe if I simply add
>>>   perl5.branches 5.8 5.10 5.12 5.14 5.16 5.18 5.20
>>> to the PortGroup and then start removing "perl5.branches" from
>>> individual perl ports? If so, I would add that line, but I need a
>>> confirmation from more experienced users.
>> 
>> And why again is this preferable to listing perl5.branches in each p5 port like we have now?
>> 
>> The reason why it's in each p5 port now is that it is each p5 port's responsibility to know and declare which perl versions it's compatible with. The perl5 portgroup can't know that.
> 
> The advantage would be that adding "5.20" to the PortGroup would
> enable p5.20-foo for all modules. But yes, we would need to manually
> rebuild all the perl modules on the buildbots. This means collecting a
> list of modules and passing it to each buildbot once (a better option
> would be to pass a directory to the buildbot and ask the buildbot to
> build all modules).
> 
> The incompatible modules could then blacklist their incompatibility
> with the latest perl version when needed.
> 
> Currently the problem is that lots of modules are perfectly
> compatible, but one can only add 5.20 once all the dependencies add
> 5.20.
> 
> In other cases the modules are again perfectly compatible with perl
> version X, but one of the dependencies is broken. For example
> p5.10-parse-cpan-meta (https://trac.macports.org/ticket/42146) or
> p5.14-extutils-xspp (https://trac.macports.org/ticket/43157) make *a
> lot* of p5.10-foo and p5.14-foo modules broken. Not because modules
> themselves are incompatible, but because we have a broken perl
> installation. It's not clear to me whether modules should then list
> incompatibility with that perl version or not.
> 
> I cannot imagine anyone actually checking if all the 2000 modules
> (cca. 1000 modules for perl 5.18 and 5.20) work properly and are
> compatible with Perl 5.18/5.20. So if we ever want to reach the point
> porting all the modules to Perl 5.20, this will have to be done with a
> script.
> 
> Now imagine a module where the maintainer actually checked and
> confirmed that a particular module doesn't work with 5.20 and thus
> left it out on purpose. How would such a script distinguish that
> deliberate decision to leave 5.20 out and 999 other ports where the
> lack of 5.20 is just because nobody cared enough to add support for
> 5.20 to either that port or to one of the zillion of its dependencies?

That's a good point. I've seen some ports where a comment has been added explaining why a perl version is not available, but that's not easily findable by a script.

If we instead by default opt in to all currently-available versions, then when a maintainer deliberately opts out of a perl version--maybe because the code is not compatible with newer perl versions--then whenever a newer perl version is released that too will have to be excluded in that port. But that might be a better situation than what we have now. Better to add a couple subports that don't build, than not add a thousand subports that do.


> I agree that explicitly listing a perl version is better in principle,
> but I cannot imagine it working the way we would want it to work.

Note that this is also the approach we use for php, python, and ruby. For php it works well since there are relatively few php extension ports and I take care of adding new php versions to them when they're released. For python it seems to work ok though it could work better. I'm not sure if anybody's keeping the ruby ports updated these days. And for perl it certainly has lots more modules than those other languages.


>> Additionally, a port only gets indexed when that port is modified. So consider some future point in time where perl5.branches is only in the perl5 portgroup and has been removed from all p5 ports, and now you add 5.22 to perl5.branches in the perl5 portgroup. None of the existing p5 ports will gain knowledge of that change until they are themselves modified.
> 
> I didn't think of that. Some "svn propset" to "touch" the ports would
> work, but it's also a bit annoying to do. (Or a modification to
> PortIndex to handle special cases, but that's also suboptimal.)

Changing svn properties and file metadata wouldn't be sufficient. It would have to be a change to the content of the portfile--even a whitespace change would be enough--that gets committed to the repository, so that the portindex reindexes those ports and adds the new subports.

> 
>> Why is that preferable to just leaving the perl5.branches line in each p5 port and updating it as needed, as we have now?
>> 
>> It's not, which is why we changed it 2 years ago to move perl5.branches from the perl5 portgroup into each p5 port.
>> 
>> http://trac.macports.org/ticket/34784
> 
> What's your suggestion about the best way to get the major part of
> p5.18 and p5.20 modules working then?
> 
> Mojca