Wednesday, August 29, 2007

What's in an OS X Package (.pkg) file?

I recently had occasion to figure out how packages work on OS X. This isn't an extensive treatise on the subject, and I didn't bother to look for any docs. This is just some poking around I did in the Finder and mostly in Terminal.

The original motivation was that I wanted to uninstall a package that I'd installed. The package file is Subversion-1.4.4.pkg. The first thing I learned is that packages are another case where a directory (aka folder) shows up as a single file in the Finder. You can see the contents in the Finder by control-clicking on the package file and selecting Show Package Contents. The Finder opens up a new window (just like any other folder).

All I see in my package is a folder called Contents. Within that folder, is a file called Archive.pax.gz, which is a compressed pax archive. Pax is an archive program like tar and cpio. (Actually, it's an experiment on genetic engineering - in order to "solve" the tar vs. cpio wars, they merged the two and called it pax, Latin for peace.) The pax archive was subsequently compressed with gzip - hence the gz extension.

Too see what's in the archive, we need to decompress it and get pax to print a listing of the contents. I did this as follows, although there are other ways to skin this cat:

cd /tmp
gzip -d < Subversion-1.4.4.pkg/Contents/Archive.pax.gz | pax -v

(Pax contains an option to do decompression, but I'm too old fashion.) Note that I redirect the compressed archive into gzip. I did this because I wanted to leave the archive compressed. I could have decompressed the archive and then ran pax on that, but I wanted to leave the entire package unharmed. The first bit of the output looks like:

-rwxr-xr-x 1 root wheel 1664424 Jun 22 23:57 ./usr/local/bin/svnadmin
-rwxr-xr-x 1 root wheel 1571744 Jun 22 23:57 ./usr/local/bin/svndumpfilter
-rwxr-xr-x 1 root wheel 1664612 Jun 22 23:57 ./usr/local/bin/svnlook

So, we can see that these are the files that got installed (in /usr/local). One nice thing to note is that the path names are all relative - they begin with "./" rather than just "/". This means the files can be installed anywhere - change into a directory, extract the archive, and the files will show up in a directory called usr/local below your current directory.

How can I use all of this to uninstall these files? Again, there are many ways to skin the cat, but here's what I did. I extracted the archive to /tmp. ("I thought you wanted to remove the files. Why are you extracting them again?" Patience, my friend.)

cd /tmp
gzip -d < Subversion-1.4.4.pkg/Contents/Archive.pax.gz | pax -r

This creates all of the files, but under /tmp - e.g., /tmp/usr/local/bin/svnadmin. I can now use find to get me a list of just the files:

find usr -type f -print > /tmp/fff

I then looked through the file names in /tmp/fff, and they made sense, so I removed them all.

sudo rm -i `cat /tmp/fff`

The sudo command was needed because the files were not owned by my user ID. The package installer asked for the administrator password and installed the files owned by root (as I recall). Of course, I could have avoiding "installing" the files in /tmp by running the output of pax -v through some awk or perl, but the archive was small, and I knew the options to find off the top of my head - I would have had to look up some awk or perl, since I don't use them that often any more.


P.S. This post almost never was: Blogger mangled the fonts repeatedly, and I almost gave up on it. Stupid JavaScript HTML editors!


Travis Briggs said...

Boy am I glad this post "was". I'm using this technique to uninstall files I got from a .pkg file.

Unknown said...

It's an old post but It's still be useful to know how to decompress pkg files. I would rather do "pkgutil --expand your.pkg directory"

Unknown said...

"man pax" shows that files defined in the pkg as having absolute paths from / will not wind up in your /tmp directory, but instead will go to some absolute place in the filesystem.

The -r option description in man pax recommends to use the -s option to replace leading slashes for this reason. This appears to be the only way you can be sure all files wind up in the defined extraction directory.