perl5.20

[Mojca Miklavec]

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?

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.

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

> 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