Port xapian-bindings' dependency on MacPorts' (outdated) ruby port
René J.V. Bertin
rjvbertin at gmail.com
Thu Apr 16 03:34:03 PDT 2015
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
More information about the macports-dev
mailing list