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

[David Evans]

On 8/12/14 7:15 AM, Mojca Miklavec wrote:
> On Tue, Aug 12, 2014 at 3:02 PM, David Evans wrote:
>> 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.
> And who is volunteering to do the merging? That's a serious question
> because I'm most certainly not. The problem is that I need to either
> revbump or upgrade every single Perl package. I can upgrade the
> package in the test branch, but when someone else makes exactly the
> same upgrade in the trunk before the "merge", one needs to revbump the
> updated port. So it's not really trivial to merge the changes.
I'd be happy to help with this.  It's true that many ports are outdated
version-wise (even ones that have already been ported to p5.20)
and my recent experience suggests that many need updated
dependencies as well.

To make things manageable, I would suggest limiting your initial changes in
a test branch to just your patches to the perl ports themselves and the
required rev bumps. Getting everything up to date, 5.18, 5.20, etc can
then be handled as a separate process.

When testing has been completed and everyone is happy then you just
need to merge the then content of trunk to test and update your rev bumps
as necessary.  A tool to compare trunk versions to test versions would help
at this point. Then merge back to trunk, make a final check and commit. 
No need to freeze trunk until you are ready to take these final steps.

Again, I'd be glad to work with you to share the load both in merging and
testing and I'm sure there are others interested in perl who could help
as well.
>
> Other than that I can definitely create a new branch to simplify
> testing and add the same patch to all perl versions. 
Great.  I look forward to trying this out.

Dave