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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
