7 ms·

i am a new mac user (and new to *nix in general). i was trying to get mapnik with postgres working on my mac yesterday and it took me 5 hours to get macports /

i am a new mac user (and new to *nix in general). i was trying to get mapnik with postgres working on my mac yesterday and it took me 5 hours to get macports / mapnik setup, and after most of my day was done it turns out that ImageMagick via macports and snow leopard don't mix. (Finally I tried downloading the binary for ImageMagick but then macports doesn't recognize it..) Very frustrating. Is there really nothing better, or am i just too much of a noob? What is the reason for making me build it instead of doing soemthing like apt-get on ubuntu?

telemachos 16y ago
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 16y 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? :-) ).
  - ant5 16y ago
    > ... 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.
ant5 16y ago
What is the reason for making me build it instead of doing soemthing like apt-get on ubuntu? Originally, because around '00 Apple asked some Debian people if they minded if Apple used dpkg, and GPL non-withstanding, Debian said (paraphrasing): No, you evil capitalist pigs. Or at least that's how I remember it being related to me at the time when it was explained why, in the interest of open-source peace and PR, we couldn't using dpkg =) But now, realistically? Because nobody invests the time in doing it. MacPorts can actually spit out dpkgs, rpms, and apt-get and yum repositories, but nobody has brought the rest of the glue together to actually build and distribute binaries using it.
- rdtsc 16y ago
  > Debian said (paraphrasing): No, you evil capitalist pigs. Oh, please... Apple could have used dpkg if they wanted to. dpkg is open source software released under the GPL license. Apple just chose not to, because they would have had to open source all their code that linked to dpkg libraries. That is the price they would have to pay for piggy-backing on the efforts of many volunteers and gain immediate access to a state of the art packaging system. But of course Apple being Apple has a lot more money to spend on PR and along with the help of their fan boys, the story turned into "Debian developers are mean, capitalism-hating hippies". I am not really surprised.
  - ant5 16y ago
    > Oh, please... Apple could have used dpkg if they wanted to. Apple chose not to given the apparent community stance. > dpkg is open source software released under the GPL license. Apple just chose not to, because they would have had to open source all their code that linked to dpkg libraries. > That is the price they would have to pay for piggy-backing on the efforts of many volunteers and gain immediate access to a state of the art packaging system. Neither dpkg nor apt-get have any libraries to link against, so that really wasn't the issue. > But of course Apple being Apple has a lot more money to spend on PR and along with the help of their fan boys, the story turned into "Debian developers are mean, capitalism-hating hippies". I am not really surprised.* This isn't an Apple PR story. This is something I just told you, recollected from nearly a decade ago when the mere possibility of using dpkg was on the table. ... Although, I have to say, your modern response really rather lends some credence to my ancient recollection.

telemachos 16y ago

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 16y 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? :-) ).
- ant5 16y ago
  > ... 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.

ant5 16y ago

What is the reason for making me build it instead of doing soemthing like apt-get on ubuntu? Originally, because around '00 Apple asked some Debian people if they minded if Apple used dpkg, and GPL non-withstanding, Debian said (paraphrasing): No, you evil capitalist pigs. Or at least that's how I remember it being related to me at the time when it was explained why, in the interest of open-source peace and PR, we couldn't using dpkg =) But now, realistically? Because nobody invests the time in doing it. MacPorts can actually spit out dpkgs, rpms, and apt-get and yum repositories, but nobody has brought the rest of the glue together to actually build and distribute binaries using it.

rdtsc 16y ago
> Debian said (paraphrasing): No, you evil capitalist pigs. Oh, please... Apple could have used dpkg if they wanted to. dpkg is open source software released under the GPL license. Apple just chose not to, because they would have had to open source all their code that linked to dpkg libraries. That is the price they would have to pay for piggy-backing on the efforts of many volunteers and gain immediate access to a state of the art packaging system. But of course Apple being Apple has a lot more money to spend on PR and along with the help of their fan boys, the story turned into "Debian developers are mean, capitalism-hating hippies". I am not really surprised.
- ant5 16y ago
  > Oh, please... Apple could have used dpkg if they wanted to. Apple chose not to given the apparent community stance. > dpkg is open source software released under the GPL license. Apple just chose not to, because they would have had to open source all their code that linked to dpkg libraries. > That is the price they would have to pay for piggy-backing on the efforts of many volunteers and gain immediate access to a state of the art packaging system. Neither dpkg nor apt-get have any libraries to link against, so that really wasn't the issue. > But of course Apple being Apple has a lot more money to spend on PR and along with the help of their fan boys, the story turned into "Debian developers are mean, capitalism-hating hippies". I am not really surprised.* This isn't an Apple PR story. This is something I just told you, recollected from nearly a decade ago when the mere possibility of using dpkg was on the table. ... Although, I have to say, your modern response really rather lends some credence to my ancient recollection.