|
|
|
|
|
|
by JadeNB
5823 days ago
|
|
|
> What MacPort "sees" is what's in /opt/local with its tools. I'll bet the binary you got installed ImageMagick into /usr/local. It's actually worse than this; MacPorts maintains its own idea of what's installed, and, while you can put your files in its directories, that won't fool it into believing that ImageMagick is installed if it hasn't done it itself. (People have asked MacPorts for ways to work around this—to avoid installing all the X libraries again just to use an X application, for example—but, as near as I can tell, this is a design decision.) Also, it's 'true enough', but not always true, that MacPorts looks in /opt/local. For example, I'm finicky about having one easily backed-up directory for everything that I install, so mine is in /Users/Shared/Applications/Utilities/MacPorts (much easier to type, no? :-) ). |
|
|
Yes. A very long time ago, MacPorts relied on file dependencies; if a library was there, it was used.
The problem that emerged was that these dependencies often broken. Sometimes Apple shipped a broken update, sometimes users installed broken software.
This would cause MacPorts to break.
If Apple shipped a broken update (eg, openssl headers that didn't match the openssl library), MacPorts had to switch to their own openssl package in order to be able to keep building software.
If users installed broken, too-old, or otherwise non-suitable packages, the MacPorts developers had to help debug their rather random systems to figure out the problem.
When you couple this with OS-shipped dependencies that go stale, you necessarily see your dependency tree begin relying on internal dependencies for almost everything, and due to all the software deployed using those dependencies, you can't cull them from the tree.
So instead you wind up maintaining a controlled, parallel universe. It's foolish to think this won't happen with Homebrew, too.