[jdbeast00]

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?

[ant5]

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]

> 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]

> 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.

[rdtsc]

> Apple chose not to given the apparent community stance.

Apple still could have used it. It is open source, that is the point of open source. Redhat might not like that CentOS is recompiling their source and release their distribution. But there is nothing they can do.

> Neither dpkg nor apt-get have any libraries to link against, so that really wasn't the issue.

Not true. There is libapt, synaptic depends on it, for example. Unless they intended their users to open terminals (oh the horror), they would have had to link against libapt to create a responsive installer GUI. Otherwise they would have had to parse stdout of external processes.

> 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.

I understand it is not an Apple PR story in this case. It just seemed that the story wasn't true and it seems to me often enough the untrue stories always favor those who have most fanboys or largest PR pockets.

[ant5]

> Apple still could have used it. It is open source, that is the point of open source.

Yes, but Apple chose not to. It had nothing to do with legal reasons.

> Not true. There is libapt, synaptic depends on it, for example.

Sorry, you're correct. There was a nascent libapt, but at the time, we just wanted dpkg, and as rbanffy noted, we could always run apt as a separate binary.

It really wasn't a "fear the GPL" response.

> I understand it is not an Apple PR story in this case. It just seemed that the story wasn't true and it seems to me often enough the untrue stories always favor those who have most fanboys or largest PR pockets.

OK. But it's why I was told we couldn't use dpkg. I don't know if you recall what Apple and Mac OS X was like before the 10.0 release, but both were very different beasts than they are today, and Apple had some very different priorities in respect to UNIX, the existing UNIX community, et al.

[rbanffy]

> Unless they intended their users to open terminals

They could run it on a separate process and deal with stdin/stdout within a GUI program. No problem that way either.

[rdtsc]

Even better they could have assigned some devs to create dpkg and apt options to output stdout data in a structured format (xml for ex) to facilitate this kind of interaction. Bazaar has that for example.

The downside is that that could significantly slow down the application, depending on the types of queries and commands that are performed.

[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.