On Apr 25, 2013, at 08:41, Daniel J. Luke wrote: > On Apr 24, 2013, at 11:35 PM, Ryan Schmidt wrote: >> On Apr 24, 2013, at 15:23, Andre Murbach Maidl wrote: >>> I'm a Computer Science student and I'm currently working with >>> Lua, so I'm interested to propose a way to integrate rockspecs >>> from luarocks to macports. >>> >>> After my talking to neverpanic on the irc channel, I realized >>> that a simple script to generate Portfiles from rockspecs >>> wouldn't be enough for GSoC. >>> >>> Then he told me that maybe an API to deal with 3rd-party >>> package managers could be enough for GSoC. >>> However, he also told me that there is an open question: >>> do we need an API to achieve that, or can it be done >>> with what we already have? >> >> What other package managers are you thinking of? In what way do you want to >> integrate them with MacPorts? >> >> MacPorts already has ports for packages from cpan and pecl, and from the >> ruby and python package repositories. Most of these are created manually, >> though for cpan there is the cpan2port script that can be used as a starting >> place. > > It would be cool, for instance, if port could call out to a modified cpan (or > cpanm, or something else) to have it build a perl module so we would always > have every available perl module (I think someone mentioned that fbsd ports > does something like that).
That's been talked about before. What happens when another port wants to declare a dependency on a CPAN module? Currently, that other port writes "depends_lib port:p5.12-foo-bar" or whatever, and through the subport directives of the perl5 portgroup, the file perl/p5-foo-bar/Portfile is found and its instructions are followed. If you're proposing that we no longer have a Portfile for every port, and that some ports exist "virtually" and are passed through somehow automatically to CPAN, then I worry that that's so different from how MacPorts works today that it would be a massive amount of work to get right, and could easily cause problems at various edge cases. And what happens if a CPAN module doesn't work for us out of the box? Do we then fall back on creating a normal Portfile so that we can patch the source etc.? We do need a good way to get packages from other collections into MacPorts and keep them updated, but I thought we were going to do that by developing scripts to automate the creation of Portfiles, like cpan2port already does to create CPAN ports. I initially wasn't sure if this is what was meant, and it now seems like it isn't, but I would not support an effort to integrate with package managers that compete with MacPorts for installing normal programs and libraries, for example Gentoo Portage or FreeBSD Ports or Debian APT. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
