Daniel J. Luke dluke at
Mon Jul 28 07:16:45 PDT 2014

On Jul 27, 2014, at 9:15 AM, Ryan Schmidt <ryandesign at> wrote:
>> I cannot imagine anyone actually checking if all the 2000 modules
>> (cca. 1000 modules for perl 5.18 and 5.20) work properly and are
>> compatible with Perl 5.18/5.20.

all of the cpan hosted distrobutions should come with a test suite that gives a relatively good idea if the module works or not.

>> I agree that explicitly listing a perl version is better in principle,
>> but I cannot imagine it working the way we would want it to work.
> Note that this is also the approach we use for php, python, and ruby. For php it works well since there are relatively few php extension ports and I take care of adding new php versions to them when they're released. For python it seems to work ok though it could work better. I'm not sure if anybody's keeping the ruby ports updated these days. And for perl it certainly has lots more modules than those other languages.

If we only installed one version of perl5, this would be a lot easier (and we'd have a chance at having things actually work relatively smoothly).

>> What's your suggestion about the best way to get the major part of
>> p5.18 and p5.20 modules working then?

In a dev repo (on someone's machine):

replace perl5 symlink port with a port for perl5.20. Update the perl5 portgroup to just make p5-foo ports that work with whatever the current perl5 port is (and reindex locally). Run a script to build/test all of the p5 ports (maybe temporarily modify port to auto-run the test suites to help).

Once this works reasonably well, commit the changes ;-)

- some way to mass rev-bump/force rebuild/force reinstall of all p5 ports when the perl5 port changes (ideally something that could be done from within the perl5 portgroup, so it can be done in one place)
- better cpan integration 
	- so we don't have to maintain a p5 port for each module that we want to include / be able to depend on
	- so end users can use something like 'cpanm' to install modules and have them be managed (for upgrade/uninstall/etc.) like regular macports ports

Daniel J. Luke                                                                   
| *---------------- dluke at ----------------* |                          
| *-------------- -------------* |                          
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          

More information about the macports-dev mailing list