Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Fink or Macports?
15 points by yourabi on May 31, 2008 | hide | past | favorite | 37 comments
I've been using Ubuntu for several years (2006) and have grown really accustomed to having all my favorite (open source) software easily installable (django, mysql...etc)

I've recently started playing around with a Mac (Leopard) and I'm rather un-impressed with both Fink and Macports (compared to apt-get with Ubuntu repositories). However, I'm willing to accept that this is because I haven't gotten used to things.

So I'm asking the HN community: Which do you prefer, and why?




"MacPorts is the worst form of software configuration management on OS X, except for all the others that have been tried."

        -- Winston Churchill, famous Mac user


One of the problems with all these systems is that they don't identify which software components are already installed on OS X by Apple natively, and to use those for dependencies when possible. So you wind up with two Perls, two Pythons, two Rubys, etc., each with slightly different versions...


That's a feature, not a bug. Your original system stays clean and if you mess up your fink or macports installation you can just throw the whole thing in the trash and start over from scratch.


What's wrong with only installing Python/Perl/Ruby if the native one doesn't satisfy the dependencies, as opposed to (currently) installing it every time?


The problem is that the versions of the non-macports Ruby/Python/etc aren't managed by the ports system. So you're in for weird dependency mismatches if you upgrade your system version of Python.

Self-contained keeps it simpler. Just use a script to set up your $PATH as needed.


The people who tried to get the Gentoo Portage system running on OS X a few years ago tried that idea. It ended in tears.


one of the Oreilly tiger manuals gives stern warnings not to move or rename or delete the perl and python that tiger installed. I think that still goes for Leopard, as well as for the factory ruby


I feel MacPorts has a better design conceptually, but having used it for the past few weeks, I feel the execution isn't quite there yet. I also get the feeling that the team is very slow on MacPorts.

Fink uses a dpkg/apt-like system, which means binaries are pre-compiled for you. So you lose in flexibility (which is why I feel ports has a better design), but I suspect (having not used it in a while nor for long) that the team is better.

There's also Gentoo Prefix which has ported Gentoo's Portage over to other OSes, including OS X. They're pretty good, but lacking in package selection. I ported over at least a dozen packages in the 2-3 weeks I used them (it's 1-3 commands in 85% of the cases).


I had never heard of Gentoo Prefix... I will give it a try tonight.. THANK YOU!


I tried both and, coming from FreeBSD, I was not impressed. I decided to build everything myself and this has so-far been the best solution for me.


I'm working on a big piece of software with numerical, real-time, and GTK components. It needs 230 packages installed using MacPorts. I have a 20-line script, mostly "port install XXX" which takes care of it all with no worries. And it's really nice that I can just rm -r /opt and do it again if I mess it up.


I tried both, coming from Windows, and both seem to work fine. What's better about FreeBSD's Ports?


make install clean (in a ports dir) usually just works. It fetches dependencies, deals with dependence versioning correctly, applies already tested FreeBSD patches, etc. Add to that csvsup and portupgrade, which help you upgrade everything correctly in essentially one full swoop, and the whole system is hard to match.


That's been my general impression with the Unix half of OSX: it is Unix, it's just ... mediocre. Everything is just more of a pain in the ass than it would be with FreeBSD or Linux.


I used fink for a couple of years, and dropped it about a year ago. Things might have changed for the better, but when I switched to MacPorts (it was still DarwinPorts back then), fink sported packages many years out of date. Looking at the project page now, I see that its stable release still dates back to June 2006. Maybe the unstable branch has more recent packages, but I don't have the slightest desire to run anything flagged "unstable" or "testing" on my main machine. I've done that in the past, on a Debian machine, and became tired of dealing with broken libc and binlib packages.

MacPorts works way, way better. Most ports I care about are up-to-date. Ubuntu packaging is nice, but, for example, its git-core package is several versions behind the one in MacPorts. It has a couple of minor annoyances with cleaning up old versions of packages, but otherwise works like a charm.


Both and neither. On a case-by-case basis, I will do some light google research on the experience of the mac-unix community for that particular package. Sometimes either the fink or ports release is recommended over the other, sometimes a stand-alone installer has been made, and often I just choose to compile from source. The decision is usually based on factors including latest version available (fink and ports are not always up to date), reported stability, dependencies (I might already have some of the dependencies obtained by one particular method), etc. If the choice was just between fink and ports on their merits alone, I slightly prefer ports, but that is probably a religious decision (a la vi vs emacs, etc...).


MacPorts lacks a few contributers, I think. Actually, they welcome people willing to contribute and give commit rights liberally, when you're interested. The documentation on how you should apply to join sounds more buraucratic then it feels in reality. So if you use it and fix things for yourself locally, then consider joining as well by all means, we can only all benefit from it mutually.

As somebody working with code all the time, I like MP's approach of compiling yourself, possibly patching memory profiling into your ruby, or whatever you might need.


The lack of a single, cohesive, well supported set of packages on OS X is the reason I do a lot of development and experimentation inside another operating system inside VMWare Fusion.


i just went through the process and decided on macports for setting up two machines. it worked fine for the basics (installed mysql, apache, python, git, etc). fyi: in both cases, i received an error installing py25-mysql, but re-issuing the port command a second time did the trick.

one possible reason for picking macports is that there seem to be more people blogging about their experiences with it, so if you run into issues, you might be more likely to find some help online.


I switched back to Ubuntu over this. (Well, this and the growing realization that I wasn't really in control of my own computer).


I will be doing this when I get the money together for a new laptop, only I'll be using Debian. I'm not a fan of everything I've been locked into as a result of this PowerBook, and even after I switch, I still have all sorts of data backed up to various hard drives formatted in HFS(+). Hopefully my information is out dated and HFS(+) is now well supported in linux.


You realize that Debian will run just fine on that PowerBook, right? The idea of saving up for a new computer to run linux , of all things, sounds awfully alien to me. :)


Yes, I realize that debian runs fine on a powerbook. However, I need a new computer anyway.


Sadly, I looked into the "best filesystem for an external drive" recently and arrived at NTFS. It's a no-brainer for Windows. ntfs-3g is already installed and working on any recent Ubuntu, and is trivial to install on OS X.

Reliability? Ask me in a year.


You may also want to take a look at pkgsrc, which lists OS X/Darwin as a supported platform:

http://www.netbsd.org/docs/software/packages.html


MacPorts is pretty decent and I use it to install all kinds of software that I need. Couple of notes though:

I frequently hack the Portfiles to tweak things and add configuration options that I need. Most packages are pretty decent but some need something special that the original maintainer did not think of.

Upgrading your MacPorts install does not work. Specially when packages have dependencies. It's just flakey. So what I do is simply delete /opt/* and install all the ports that I use again. Little painful but I think I don't do this more than a couple time a year or so.


MacPorts. I am just used to FreeBSD's port system and I don't mind to recompile code from sources. I hate dependency hell in apt/yum style system. I like the old unix way of self contain packages which can be controlled by environment variables.

Disk space is going to be like infinite in the long run. So I would rather there are many different versions of perl/python/ruby on my machines and let them to be independent from each other.


I myself considering throwing away my MacBook and get a nice Dell with Ubuntu. I just can't get things done here the way I used to have with Ubuntu.


I've tried MacPorts, and inevitably when I update the packages I wind up creating some kind of dependency issue that causes me to just give up, scrap the /opt folder and start over again.

I've just started building things from source recently. It's not hard, gives you maximum control, and is less likely to freak out if you update a given piece of software.


I hated both. My short-term solution was to compile everything by hand. My long-term solution was to switch back to Linux.


Where you... compile everything by hand?


Huh? Have you seen a Linux system in the past, oh, I dunno, 12 years? Package management on Linux is the absolute best available. apt-get/dpkg and yum/RPM pretty much rule, and you'd be nuts to choose Mac OS X package management (or the absolute lack thereof) over either of them.

There may be many wonderful things about Mac OS X, but package management is not among them. And, interestingly, it is one of the wonderful things about Linux (excepting the mildly retarded distributions...which shall remain nameless, but they rhyme with "Gentoo" and "Slackware").

The interesting thing about package management is that until you've actually spent some time with a better solution, you'll think great things about a significantly inferior solution (Mac OS X, for example, where a "package" is effectively just a big ball of crap that spews out across your system on install, and can't be verified, uninstalled or upgraded cleanly, and can't really deal with dependencies). After spending 10 years with systems that know where everything is on the system, and what the dependency chain looks like for every installed application, and can upgrade/downgrade/uninstall anything using a single command, I sit down to a Windows or Mac OS X system with what can only be described as dread.

It's the one thing that would absolutely be a deal-breaker for me, with regard to using Mac OS X heavily (particularly for development). The big ball of crap packaging is just too painful.


Not since 2002 or so. That's the last time I used LFS, because before that every Linux distribution sucked. Now I use Debian or Ubuntu server edition.


I use a hybrid of fink unstable and manual compiles. Fink unstable keeps me with relatively up-to-date versions of most of my programs, but some (git, ghc, darcs) I compile myself and install in my ~/ins folder because the fink maintainers have abandoned those packages.


MacPorts is better than Fink, but the reason this stuff all feels hinky to you is that Mac users use Mac software.

You can usually just build command line tools from "configure". But anything with a UI is likely to be a disappointment.


I've been pretty happy with MacPorts. I mostly use it for apache, git, mysql, php, postgresql, sqlite and a few other small stuff. everything works pretty fine. Django is installed from trunk.


I downloaded clisp with macports. It felt like a botched surgery: it only half worked, and I'm still recovering from the painful experience.

Definitely an exception to "it just works."




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: