changing default perl
Daniel J. Luke
dluke at geeklair.net
Mon Nov 11 07:35:22 PST 2013
On Nov 11, 2013, at 6:06 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Nov 5, 2013, at 08:46, Daniel J. Luke wrote:
>> I would say we should even go further, and get rid of all of the p5-* ports.
>> Instead, we should install perl5 as the latest stable perl, and include our own 'cpanm' program (like how perlbrew has it's own) which would download/build/(test)/install modules (probably into a DESTROOT to allow MacPorts to do the actual install and to take advantage of Macports being able to do unininstall). We could add a new dependency type (and associated functionality) to allow ports to still depend on perl modules, and the perl5 port could uninstall/reinstall all of the installed perl modules when upgraded (or actually, on post-activate).
> If we don’t have a portfile for each CPAN module, how would we:
> * not update to a newer available version if that version did not build on OS X?
> * apply patches?
> * blacklist a compiler?
> * add a flag to CFLAGS?
> * check the license to check if a dependent is distributable?
> It seems like each of these would require special workarounds, which are not needed with the current way of creating a portfile for each package.
I would suggest that in the case of perl modules we shouldn't be doing any of the above (ie, just fix bugs in upstream and not bother building archives for them).
It would certainly be possible to have some local metadata that our cpanm could consult to do any of the above, though.
The main benefit would be that /all/ of the modules would be available in a MacPorts supported way and they would be up-to-date without an army of volunteers building cookie-cutter portfiles for them.
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-users