location of libperl.dylib and other dylibs
Daniel J. Luke
dluke at geeklair.net
Fri Apr 4 08:09:59 PDT 2014
On Apr 4, 2014, at 11:05 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Fri, Apr 4, 2014 at 10:26 AM, Daniel J. Luke <dluke at geeklair.net> wrote:
> On Apr 4, 2014, at 10:00 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
> > People are still trying to figure out how to deal with perl ports; there was a recent aborted attempt at building a port select mechanism for it instead of that perl5 metaport with variants, which ran into lots of problems. The whole thing is annoyingly tricky to deal with, and the solutions don't appear to be simple. :(
> We should mostly get out of the business of the perl p5 ports (or as much as possible).
> - offer one perl5 (the most recent stable release, currently 5.18.2)
> - make a glue layer that lets ports depend on modules, but has something like a custom cpanm actually do the install
> - maybe also have some 'rebuild all modules' magic that we can have the perl5 do when it gets upgraded
> ... but so far, not many other people agree with me on this ;-)
> I can think of problems with that proposal. There aren't any good solutions, sadly.
problems that are worse than the current situation?
care to elaborate on your specific concerns?
(I realize that getting the glue + magic right may be difficult, but the reality is that there aren't enough maintainers who want to actively maintain the p5 ports that we have, let alone the other cpan-listed modules that we don't have...)
I'm certainly personally guilty of not really spending time making sure my p5- ports are up to date ...
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