PackageMaker

PackageMaker

For Mac OS X Server

PackageMaker is 'Yet-Another-GUI-For-The-Package-Tool'. In addition to keeping you away from the command line, it allows you to store the parameters in a settings document, can build and organize multi-package files (.mpkg), will look for common problems (such as file ownership and setuid), and can compress the result with gnutar.

This release adds a 'Preflight warnings are errors' option, and checks for ownership and permission problems with the package source directory('.').

Winner of the 1999 Stepwise Cocoa Application Contest
Editor's Choice Award!

Screenshot

Release History

12/27/1999 - 1.0b4
Added 'Treat Warnings As Errors' option,which is selected by default. Added pre-flight check for ownership and permissions of source directory ('.'), since they get applied during package installation as well.

11/23/1999 - 1.0b3
Added pre- and post-delete script options, ability to include arbitrary files (such as tools) inside the .pkg wrapper, ability to add a 'ReadMe' file outside the .pkg but inside the .tgz archive .

10/18/1999 - 1.0b2
Added pre- and post- install script options, reversed color scheme in source list window (now the entire line of the 'problem' file is blue with the suspect attribute column red.

10/5/1999 - 1.0b1
Fixed problems with the PackageMaker.pkg install package (quite embarassing, that...).

9/30/1999 - 1.0b
Initial Release.

Fixed some bugs regarding updating changed attributes for sub-packages inside multi-package projects. Changed Description field to reject returns and tabs.

Fixed several NSInputManager-related bugs involving closing new documents with changes and then not saving them. Seems to be framework-related, since many other NSDocument-based apps suffer the same problem (including the Yap example program from Apple). To replicate: open a new document, make some changes (ie., type something), now close the window and click 'Don't Save'. BOOM! something talked to a freed object. Now instead of crashing the app every time this is done, it only happens sometimes (much more seldom). There is a thread on this (including a workaround) on the MacOSX-Dev mailing list at Omnigroup.

Changed the package and multi-package project file format (which breaks existing package projects, sorry...) to allow future expansion of the format while staying backwards compatible from now on. I just added a PackageInfo version number attribute, and an NSMutableDictionary 'expandedAttributes' member. Attributes added to the file format in the future will simply be added to the dictionary, thus staying compatible with older project files.

Prepared the source for release, and in the process eliminated several other small bugs, leaks, and crufty places.

Known Bugs

I've run into an intermittant bug that will crash PackageMaker with a 'message to freed object' exception occasionally when a window is closed. It seems to happen more often when closing a new .pkgmaker or mpkgmaker file without saving it, but of course, not every time (that would be too easy to find, right?... ;-) ). At times, it takes on the appearance of a Heisenbug, since it never seems to happen when running under gdb.
It also doesn't really hurt anything, since saving the file first seems to prevent it from happening. As soon as I take the time to nail it down, I'll post a fix (Quality is Job 1.1!).

To Do

After receiving some user input, and putting some more thought into the subject, I've come up with several more interesting directions this could go:

I'd like to add the ability to export a 'package-build' script that would invoke the package tool with the parameters set in the PackageMaker project, including post-build compression. This could be pasted into the bottom of a Makefile.postamble, and automate the package build process. I'm sure there are already plenty of people doing this, but this could make it easier.
I've received some feedback suggesting that I switch to a file-directory wrapper format, and keep all of the information for the package in there, instead of using NSArchiver as I do now. I've been thinking quite a bit about this, and while I see the wisdom of it, decided not to for this release. The advantages I see would be a format more resiliant to changes, binary compatibility of project files across Cocoa platforms, and a better likelihood of recovering partial information after file corruption. The downsides are that after envisioning exactly what I'd have to change to do this, I don't like the architecture I'm ending up with yet. With an NSArchiver-based format, I like the way that sub-packages of Multi-packages are actual, full-fledged package project objects, exactly the same as if they were stand-along package project objects. Much of the code ends up being in just a few classes, and there's very little duplication. I've also got several other apps I'm working on, and don't want to have to test and debug everything again right now. Maybe version 2.0.
I've considered adding the ability to accept file drags from the Workspace.
The pre-flight functionality could get considerably smarter, such as double checking the permissions on any standard directory trees (ie., /usr, /Local or /System).
If there's a strong need for it, the ability to import existing .info files could be added.
If anyone can describe the format of an .hfspkg file, and also explain what they're needed for, that would be another possible addition.
If I were Microsoft, I might add the ability to automatically transfer the finished package archive to a given url, but I'm not, and that would be bloatware...
Before I put too much time into this, I want to see where Apple intends to go with the install system. If they go to the Debian system, all of this would obviously be pointless.

Goto Downloads Page