perl5.20

[Mojca Miklavec]

On Mon, Jul 28, 2014 at 4:16 PM, Daniel J. Luke wrote:
>
> 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).

And we would probably be stuck with nobody daring to upgrade Perl to 5.22 ;)

>>> 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 ;-)

A testsuite to test all the thousand modules would certainly help.

> TODO:
> - 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)

That's what I suggested a few posts back. And I was told that this is
a problem because one would have to modify all the thousand ports
anyway, else index wouldn't see any chance.

> - 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

Yes, that's certainly needed.

I would suggest having a single huge file with a list of modules from
CPAN where the versions and checksums would be automatically fetched
from CPAN. On top of that I would keep the Portfiles (if and only if
needed) for any additional changes that need to be done.

>         - so end users can use something like 'cpanm' to install modules and have them be managed (for upgrade/uninstall/etc.) like regular macports ports

That would be nice.

Mojca