[telemachos]

Short answer: it's not you; it's Apple, mostly. There is nothing for OSX as good as the APT tools. Apple provides a good selection of nix tools, but it cripples some, rarely updates them and has zero investment in a larger tool-set for dealing with them.

All the community solutions are imperfect. What MacPort "sees" is what's in /opt/local with its tools. I'll bet the binary you got installed ImageMagick into /usr/local. (That's pretty common.) Welcome to *nix package management, sadly.

[JadeNB]

> 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? :-) ).

[ant5]

> ... near as I can tell, this is a design decision.

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.