ryandesign at macports.org
Sun Jul 7 20:00:43 PDT 2013
On Jul 7, 2013, at 13:51, Mark Anderson wrote:
> Yeah. That was why I sort of just floated it as an idea. Mainly because of my troubles with a certain OSX that is not to be named or the fiery NDA demons will smite me.
> And now that you mentioned curl and subversion it's making more sense to me, since Macports likes to rely our own stuff to maximize compatibility.
Thus far, MacPorts *ports* like to rely on other MacPorts ports for maximum compatibility and consistency between OS releases. However, thus far, MacPorts *itself* has never relied on MacPorts ports. In fact, just naively making MacPorts base link with libraries provided by MacPorts ports would be brittle and unwise, e.g. if MacPorts base used a library from MacPorts cURL, and the user deactivated MacPorts cURL, then MacPorts wouldn't be able to use cURL anymore. But as I said it's possibly worth looking into ways of solving it. For example, a person preparing a MacPorts base release could use MacPorts to build cURL, and then include that pre-built cURL in the MacPorts installer, which would install it into a secluded location and which would only be used by MacPorts itself.
A separate problem, but one which including our own libraries for cURL, Tcl, Subversion and so forth might be a step toward solving, is the ugliness of having a separate MacPorts installer per version of OS X.
More information about the macports-dev