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

[David Evans]

On 8/12/14 5:34 AM, Ryan Schmidt wrote:
> On Aug 12, 2014, at 4:15 AM, Mojca Miklavec wrote:
>> Hi,
>>
>> I would like to do a massive commit with changes in perl modules.
>>
>> I attached a patch to
>>    https://trac.macports.org/ticket/43480
>> two days ago, but it is no longer suitable as such out-of-the-box
>> since there were a bunch of changes in perl modules (including
>> changing exactly the files that I previously edited in that patch). I
>> need to revbump all the modules that were committed in-between and
>> merge some changes.
>>
>> I would really really really like to see the switch from
>>    /opt/local/lib/perl5/5.18.2
>> to
>>    /opt/local/lib/perl5/5.18
>>
>> and I already implemented that for perl 5.18 to do a complete switch
>> getting rid of the subrelease number. However this mass-update change
>> would also be the most suitable time to do the same with Perl 5.16.
>> There I would switch the default path, revbump dependent ports
>> (linking against libperl.dylib), but I would keep the line
>>
>> configure.args-append "-D
>> inc_version_list=\"5.16.3/${os.platform}-thread-multi${platsuffix}
>> 5.16.3 5.16.1/${os.platform}-thread-multi${platsuffix} 5.16.1
>> 5.16.0/${os.platform}-thread-multi${platsuffix} 5.16.0\""
>>
>> for now to avoid having to revbump all the thousand files at once.
>>
>> That would greatly reduce problems like
>>
>> --->  Scanning binaries for linking errors
>> Could not open /opt/local/lib/perl5/5.16.1/darwin-thread-multi-2level/CORE/libperl.dylib:
>> Error opening or reading file (referenced from
>> /opt/local/apache2/libexec/mod_perl.so)
>>
>> and having "problems" with perl modules installing files to different
>> subdirectories.
>>
>> I just wanted to check if anyone has anything *against* this change in
>> 5.16. I wouldn't bother about changing Perl 5.8-5.14 at this point, at
>> least not as a high priority. But Perl 5.16 is on the borderline
>> (currently the only one supported ) The idea would be to get rid of
>> support for those old Perl modules anyway.
>>
>> (But if anyone wants, I can change older perl versions as well.)
>>
>> I would be really grateful if you could hold off committing to the
>> perl modules at least a tiny bit. I tested my changes on Saturday, but
>> if too many changes are committed, that will all be double work.
>>
>> My plan would be to add 5.18 and 5.20 to other modules once this gets
>> committed, but we first need to revbump all modules that are already
>> depending on 5.18 if we want to get rid of the subrelease number
>> completely.
> If you're going to revbump all perl modules, you may as well make this change in all versions of perl, not just 5.16 and up, no? Otherwise you're revbumping p5.14-* and below for no reason.
>
>
>
+1 for Ryan here.  This will be a massive rebuild and I would prefer to
see it done once only after you have all the perl versions modified.

Also, I still think it would be prudent to make these changes in a test
branch first so that they can be tested in a wider group, voluntarily,
before committing to trunk.  This would also obviate the need to stop
current updates in trunk as these can be easily merged into the test
branch as necessary.  Then when all is ready and interested parties sign
off, the test branch can be merged to trunk.

Dave