First impression on package mangement on Mac OS X

Ok. I’ve only used a Mac for a couple days, they were certainly long days with many steep learning experiences. Here are some of my comments:

On Mac OS X, you have several options to install an application. You can use pre-packaged binaries such as Universal Binary or a platform specific installable binary for your Intel or PowerPC based Mac computers. This class of binary is equivalent to setup.exe/intall.exe on Windows except this is much better at the first glance. From the user point of view the installation process typically involves double click or click OK/Yes until you are done, which translates to about 3-4 times and this is much shorter than most other installation steps that I am used to. To me, the impressive aspect of installing applications from pre-packaged binaries is the concept of drag-and-drop of a single icon into just about anywhere you want to install the application. Behind that, there are a lot of other complexities that is being abstracted out for the user. That level of simplification is an eye opening experience for me.

Working with installable binary directly by point-and-click your way through essentially means you are managing the application portfolios by you self. This reminded me of early Fedora days when I would go to different application repositories or web sites to download individual rpm packages. Having to manage individual packages you self can become a challenging task. At least, you may loose track of which packages are getting outdated and need to be updated. In the worse scenario, you may need to figure out all the dependencies you self and install them in the correct order. This certainly isn’t the most optimal way to manage a modern operating system. Even with extreme ease of use from UI point of view, I still have to do all the clicking on each package isn’t all that exciting.

Besides the regular installable binary, you can use a package management system, Fink. It provides both a repository for many open source software and a popular command line tool, apt-get, to easily manage the packages. apt-get is a very popular tool among Linux distributions and it made me feel at ease initially. What’s unusual to me about Fink is that it isn’t just a binary package management system, it can even handle install from source code, similar to how the emerge tool from Gentoo. You can configure it to use newer unstable version of the source tree and with a single line of command, you can essentially trigger the system to download the source package from the repository, compile and install the compiled binary in a sequence that satisfies all dependencies. In addition, all software are installed in an isolated directory so they do not conflict with any existing software you may already have. This essentially is the same approach as‘s way of manage applications. Fink combines many great designs and features among many modern package management systems and it certainly looks great on paper.

In practice, I found it also suffers similar issues as emerge on Gentoo when you venture beyond the stable binary into unstable source packages. A software package may fail to build. If a such error does occur, the user may have do some heavy-weight lifting to troubleshoot the error. I did tried to build Gnucash and it failed on me. One big difference that I found between Fink and Gentoo’s emerge it it’s community. When I encountered an error when attempting to install or upgrade a package, all I had to do was go to Gentoo’s we forum and past the error message. Most of the time, I would see people’s discussion about that specific error. Many would post suggestions and solutions. Having such “howto” materials available EASILY was really useful, important, and educational to me. on the other hand, my first impression with Fink when venture out to the unstable tree has left me stranded for several days so far. It appears to me that the community activities among Fink circles wasn’t as active as other forums among major Linux distributions that I’ve worked with. So, be careful when you are thinking of turn that switch to unstable tree. I would advice you to do some search for support materials first.

In addition to Fink, you also have the option of Macports, which is a source based package management system. It requires you to download and install Xcode, a free development tool from Apple. Xcode basicly contains gcc compilers, an IDE and utilities that are geared toward developers to write applications for Mac OS X. At about 923MB download size, Xcode certainly makes Macports a much more heavyweight than other package management options. Macports works similar to Gentoo’s emerge command, except you use port command to install applications. One thing typical of a source based package management system is that it takes a lot of CPU cycles to build each application from source. If you don’t mind keeping your computer on and generating heat for extended period of time, such “need” should not bother you much. If you are mobile or have a need to shut down your system form time-to-time, you may wish to plan your windows of opportunities to use Macports. This means less practical for laptop users, who typically have a need to shutdown the laptop from time-to-time.

Furthermore, Macports is only single threaded. This can be both a good thing and a bad thing for dual-core CPU owners. It can be a good thing because you will have the other core doing something else while one core is busy working for Macports. It can be a bad thing if you don’t need to use the other core and wish that Macports can take advantage of all the processing power you have. To me, this is where I wish to see Gentoo’s behavior. Back when I had only one slow core running Gentoo, the system can be 100% busy compiling sorce code while I do my regular light-duty Internet browsing and emailing without feeling any lag. I could even pushed the system a little by watching a video, which normally pushes CPU utilization higher on a slow CPU. The trick that Gentoo did was to set the priority of the activities emerge to low to avoid slowing down any user activities. If Macports can do something similar while multi-thread the compilation process, it will be a lot more efficient, especially with the new quad-core CPUs.

In my short experience with Macports so far, it has failed to install Gnucash and MySQL correctly for me. Such efforts cost me many hours of troubleshooting and searching through the Internet for possible solutions. The out-of-box experience certainly left me underwhelmed when comparing to rest of the OS or even to popular Linux distributions.

Am I bitter? Not at all! This is kinds of stuff I deal with every day and I am learning a lot going through all these hoops. If I don’t try to experiment with all these technologies, or attempt to break it, I won’t know how it works. 😉 Even if I end-up not able to resolve some of the issues, I learned to appreciate with a sense of accomplishment when I am able to solve some of these wicket problems or finds a much easier or efficient alternatives. Such as installing MySQL from a pre-build package in .dmg format, than trying to agonizing over the issues when using Macports or found out after the fact that Fink’s MySQL is one release behind what I need. 🙂


2 thoughts on “First impression on package mangement on Mac OS X

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s