If we aren't quite ready to tackle "one perl" yet, we could still improve the situation slightly by removing all p5.8 and p5.10 modules. We wouldn't have to bother fixing some perl 5.8- and 5.10-specific issues, and it would be fewer subports for maintainers to test and for buildslaves to build.
Check my work, but it looks like there aren't any ports that depend on p5.8 or p5.10 versions of modules (other than other p5.8 and p5.10 modules of course): $ port echo depends:p5.8 and not name:^p5.8 $ port echo depends:p5.10 and not name:^p5.10 $ The question is how should we go about that. It would be straightforward to just remove 5.8 and 5.10 everywhere it is found in a perl5.branches line, but if any users still have those old modules installed, they would never receive notification that they should upgrade to newer perl versions to continue to receive updates. This is the de facto solution we are using for python modules as well. It might be cleaner to use the replaced_by mechanism to replace these older modules with newer counterparts, but that would be more work. Thoughts on whether that's necessary? Later we could remove perl5.8 and perl5.10, though at present some ports still depend on them: $ port echo depends:perl5.8 and not name:^p5.8 subversion-perlbindings-5.8 rpm rpm45 rpm50 rpm51 rpm52 rpm53 $ port echo depends:perl5.10 and not name:^p5.10 subversion-perlbindings-5.10 $ _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
