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

[Ryan Schmidt]

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.