changing default perl

[Mark Anderson]

I love the idea of a portfile override, but building from cpanm (cpanmp?)
most of the time.

—Mark
_______________________
Mark E. Anderson <emer at emer.net>


On Mon, Nov 11, 2013 at 11:44 AM, Daniel J. Luke <dluke at geeklair.net> wrote:

> On Nov 11, 2013, at 11:32 AM, Ryan Schmidt <ryandesign at macports.org>
> wrote:
> >
> >> 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 guess it could be implemented that way, but it's not really what I was
> thinking.
>
> > I like Jeremy’s idea of adding a portfile only if necessary to fix
> issues (add patches, etc.).
>
> that would probably work.
>
> >> 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.
>
> I don't really know how other languages do this (and I'm no php expert).
> I'm at least somewhat leery of trying to design the most generic solution
> for this too (I would much rather make something that works and extend it
> if it seems reasonable to do so).
>
> I think we require base/ changes if only because there won't necessarily
> be a portfile for each perl module yet there are going to be ports that
> depend on some of these modules (so we would need a way to handle that).
>
> also - having to create releases to add functionality really shouldn't be
> something that we try to hack around by pushing code some other way. Does
> our release process need some attention to make it easier to do?
>
> --
> 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.          |
> +========================================================+
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20131111/97fbe55c/attachment.html>