perl5.20

Daniel J. Luke dluke at geeklair.net
Mon Jul 28 16:35:32 PDT 2014


On Jul 28, 2014, at 6:37 PM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> 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 ;)

well, if someone is actively maintaining the (new) perl5 port, they will just decide when to upgrade to 5.22 (and what level of testing of the module ports would be appropriate).

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

seeing as the individual p5 ports probably all have test suites, this is really just wrapping that/being able to do a big test (and would be more validation than most ports get).

actually, just setting up a packaging run with perl5.20 + all of the ports would even be a reasonable half solution.

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

We may have to modify base and/or just portindex to make this possible (that's why I put it under 'TODO' :-) ).

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

that (or something like it) is probably reasonable - it's a big enough effort that whomever is putting the dev. time in should probably just do whatever they think is right (and people can offer patches if they want it to work differently).

again, I put it under 'TODO' since it's a larger effort and it will be much easier to tackle once we simplify things with our perl ports (and make it useful to use MacPorts to install/manage perl - instead of how it is now where the perl and module installs are really only useful as dependencies of other ports).

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

freebsd ports does something like this already, so we can probably use ideas from their implementation ...
--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+





More information about the macports-dev mailing list