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