fill the void

Posted
7 December 2008 @ 9pm

PackageMaker tips

At work, we’re using Apple’s built-in PackageMaker in our automated nightly builds to produce installer packages. The command-line version is very handy as we can incorporate it into scripts run every night with launchd, and for complicated package specs, the GUI version can save off a pmdoc bundle (a collection of XML files) that the command-line version can use. Still, we’ve run into two issues to keep in mind when using PackageMaker.

Relocation

Coming from Windows, Mac OS X’s ability to go “find” files scattered around the hard drive is magic. (No, I don’t count COM.) Installers can upgrade an application bundle even if it’s not in /Applications. Amazingly neat. And horribly frustrating if you’re unaware the installer can do that. We have an application bundle and System Preferences pane bundle with the same name, and for a bit, we were scratching our heads over why the application installer kept “upgrading” the System Preferences pane when we wanted it to just place the bundle in /Applications.

The issue was PackageMaker’s default. By default, it relocated the bundle it was installing to wherever a previously installed bundle by the same name was. So, an RssBucket installer would replace RssBucket.app (or RssBucket.prefPane), not just if it was in /Applications but anywhere on the file system. Apple’s Console application (/Applications/Utilities/) can show you what the installer package actually did in installer.log; search for “diverting” for relocation issues. Unchecking “Allows Relocation” in the PackageMaker GUI disables this feature.

Upgrading

PackageMaker has another interesting default. When the GUI creates a pmdoc bundle, it caches each component’s version in the XML file. It’s a strange default because when you use the pmdoc in the command-line PackageMaker, the created installer still has that cached version. So, when used in a nightly build with agvtool incrementing the build, the created installer has the version of the application used to create the pmdoc bundle, not the version of the supplied application bundle. Result: On the third day, the installer fails to upgrade. install.log says, “Application (version 1.0.0.1) was not installed because a newer version (1.0.0.2) already exists.” (I can’t remember if the second day works because the versions match.)

<component id="com.bdunagan.rssbucket" path="/Users/bdunagan/rssbucket/RssBucket.app" version="1.0">
	<mod>isRelocatable</mod>
</component>

Simply removing the version from the XML file in the pmdoc bundle solves this problem. The installer instead relies on Info.plist to determine the version. Caching the version is an odd default, but luckily, it’s easily fixed.

4 Comments

Posted by
Patrick Gallagher

19 January 2009 @ 10am

Another thing that drove me nuts about the relocation. Lets say I’m on my admin machine which I do a lot of packaging building and I have a directory somewhere of software that I’ve been building into packages for a while. In this directory I may have older versions of software still in there for previous packages. So if I forgot to uncheck the “allow relocation”, it would update the older versions I had in my ~/Documents/Packaging directory and the app wouldn’t go into /Applications like I was expecting during testing.

I used to use Package Maker 3 mainly because of its snapshot option but I instead use fseventer and Iceberg mostly now. There are a lot of options out there and I wrote a post about the different packaging options here: http://blog.macadmincorner.com/mac-software-packaging-utilities-list/