On Thursday April 16 2015 09:44:03 Chris Jones wrote:

>As far as I am concerned
>
>https://trac.macports.org/wiki/FAQ#ownlibs
>
>answers why not quite well. I see no reason to do anything differently 
>for ruby.

And AFAIAC that wasn't the question I asked :)
In fact, " Apple has a habit of not updating the libraries in Mac OS X until 
absolutely necessitated by a security vulnerability" has advantages in my book, 
exactly those that would make it appealing to depend on OS-provided libraries. 
If they're new enough - great, they'll work and that's one complexity less. 

>  For example, if we can rely on openssl 1.0.0 from MacPorts, we don't have to 
> test every port that needs ssl for every available openssl installation

I don't really get that "test every port for every available openssl 
installation". It's the port's build system that takes care of that kind of 
thing, and in any case I was thinking about per-port use-cases because (even) I 
can see how a system-wide "use as much as possible from the OS" will become a 
combinatorial nightmare. I was also thinking about things like python, perl and 
ruby - interpreters that tend to spawn countless dependencies of their own and 
tend to exist in multiple versions. Not libraries (which rarely exists in more 
than a single version).
Openssl is not an unambiguously good example IMHO. On the one hand it stands to 
reason that you want to use the latest and greatest version of this kind of 
library that has direct security implications. On the other hand, having such 
updates can also give a false sense of security as only a subset of 
applications benefit from it, and I'm not sure the overlap with common "go-to" 
apps that would actually need that security is that large. Anyway, different 
topic.

I'm more curious about other implications like additional python/perl/ruby 
packages that might be required.

And one more thing: for a long time I maintained my own parallel Python 
installations (starting before I even installed MacPorts), with tweaks to the 
build (aiming) to maximise performance, and a more uncomplicated install scheme 
(/Library/Frameworks/Python<major.minor>.framework and site-packages in 
/Library/Python/<major.minor>). I'd have appreciated it if I could have 
configured MacPorts to install python packages "into" those interpreters. I'll 
admit I also appreciate the fact packages and minor version upgrades are now 
more or less automatic (major version upgrades remain about just as much a 
headache).

R
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to