3

Among Linuxes, keeping up-to-date with MacPorts struck me as being most like Gentoo (arguably the least Mac-like entry on the shortlist of major Linux distributions). But after further experience it seems not to be exactly like Gentoo: with Gentoo, things break regularly, but you can often find a solution by Googling salient portions of an error message, and unlike computer situations in general it makes quite rational sense to try again 24 or 48 hours later if something is broken. MacPorts in this regard seems only like Gentoo in that you can get breakage by trying to keep your system up-to-date as intended.

Earlier breakage had me stumped about how to install Django; now I have Django installed, but its breaking on upgrading glib1; the last substantive change on the bug (http://trac.macports.org/ticket/21413) was about a year ago.

Is MacPorts really "Breaks like Gentoo but you can't fix it like Gentoo", or does it say "32 bit? Legacy! Ewww!" or something else? I'd like to know what a sane basic perspective is, and what I should and shouldn't expect of MacPorts. (Or if I've answered my own question in what I've said above.)

Christos Hayward
  • 1,152
  • 3
  • 15
  • 35

3 Answers3

3

My personal opinion: MacPorts (as a project) has bitten off quite a lot more than it can chew. MacPorts seemingly tries to include absolutely everything from the Linux world, and unfortunately it ends up with countless packages that have no one looking after them to make sure that they actually work. Things break and stay broken, sometimes permanently.

Instead of wasting my time with MacPorts or Fink, I now consider the following three options when I want to run open-source software on a Mac:

  1. If there is a Mac-specific installer, I use it.
  2. If there is no installer but the project is known to work on Mac OS X, I build it from source. (This is every bit as easy as on a real Linux system, if you have Xcode installed.)
  3. If it is known not to work on Macs, or if there are too many strange dependencies, I run it in a real Linux virtual machine on my Mac.
Skyhawk
  • 14,149
  • 3
  • 52
  • 95
  • 1
    Spot on, but at the very least, MacPorts can be useful before #2, but after #1. A lot of things work--but lets face it. If the OP is using MacPorts like you would use a full fledged package manager (in this case, portage), its not going to live up to standards. – Andrew M. Sep 29 '10 at 03:42
  • @Redmumba Definitely a valid option. I personally prefer #2 because I find it to have more predictable outcomes, but if MacPorts actually does work, it might save you time. – Skyhawk Sep 29 '10 at 16:10
3

MacPorts developers do their best to test on various systems and support multiple configurations. Usually there is support for the latest two releases of Mac OS X, at the moment this is 10.5 Leopard and 10.6 Snow Leopard. It even still works on 10.4 Tiger as a legacy platform, but no additional effort will be put into this to support new features.

For this, it is vitally important not to rely on the system version, but to install dependencies into the MacPorts prefix. This might result in larger lists of dependencies, but it is the best way to keep compatibility. Also, you get newer version than Apple might provide with their system, which is not updated often.

As a user you should always search and report your build problems in the issue tracker as otherwise the maintainer might not know they exist. Or you could submit patches, which make the integration process faster, or even take over maintainership for a few ports yourself. The MacPorts team is always in need of new maintainers contributing port updates or new ports. For your comparison, the number of developers is huge on Gentoo, where on MacPorts only a handful of people is actively working on the base and ports. Therefore it takes longer to isolate and fix issues. Remember all maintainers are contributing their time for free to the project.

For your problem in particular, did you check your build_arch setting in macports.conf as suggested in the comments of the ticket you linked? The default build_arch is x86_64 on Snow Leopard. Running a pure 32-bit MacPorts installation is possible, but is not supported. It is recommended to follow migration instructions into detail.

There will be software which is absolutely unable to compile for 64-bit (e.g. wine), but MacPorts will automatically rebuild dependencies with the +universal variant. This variant means there will be support for multiple architectures in a single binary or library.

raimue
  • 355
  • 2
  • 4
0

It's as bad. The only reason it isn't worse than you imagine is because Homebrew (Link) has rendered it obsolete, unless you have some masochistic desire to get your packages screwed over time and time again.

Homebrew might not have the wealth of packages MacPorts has but it'll get there and it is simple enough to tinker with, should you so be inclined, to the point where adding "formulas" for new packages is a breeze.

Glorfindel
  • 1,213
  • 3
  • 15
  • 22
João
  • 24
  • 1
  • 1
    Sorry, but Homebrew is far away from being a replacement. It might be able to automate software compilation, but it does not have any sort of dependency management and lacks other features MacPorts has. Also, as it does rely on software provided with Mac OS X it will definitely break at the next system release and I doubt it will target multiple versions of Mac OS X as MacPorts always did. Homebrew might give you a working system for now, but over the long run you will run into problems. – raimue Sep 30 '10 at 18:36