On Jul 28, 2014, at 6:37 PM, Mojca Miklavec <mo...@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
+========================================================+
| *---------------- dl...@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
