I love the idea of a portfile override, but building from cpanm (cpanmp?) most of the time.
—Mark _______________________ Mark E. Anderson <[email protected]> On Mon, Nov 11, 2013 at 11:44 AM, Daniel J. Luke <[email protected]> wrote: > On Nov 11, 2013, at 11:32 AM, Ryan Schmidt <[email protected]> > 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 > +========================================================+ > | *---------------- [email protected] ----------------* | > | *-------------- http://www.geeklair.net -------------* | > +========================================================+ > | Opinions expressed are mine and do not necessarily | > | reflect the opinions of my employer. | > +========================================================+ > > > >
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
