On Nov 11, 2013, at 09:35, Daniel J. Luke wrote: > On Nov 11, 2013, at 6:06 AM, Ryan Schmidt 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).
Ok but we certainly have experience with software developers not responding to tickets or patches for months or years. > It would certainly be possible to have some local metadata that our cpanm > could consult to do any of the above, though. This sounds like inventing a second language to do what we can already do in portfiles. I like Jeremy’s idea of adding a portfile only if necessary to fix issues (add patches, etc.). > 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. And that would be great! If we do this, we should find a way to make it abstract so that we can integrate other package managers besides CPAN. For example we have the same problem for php’s PEAR package manager: two years ago, Bradley put all of PEAR in MacPorts, but it hasn’t been updated since then. Perhaps this functionality could still be implemented as portgroups, or at least as tcl files in the _resources directory, so that new MacPorts base releases are not needed to make changes there. _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
