Here's how to run things:
HelloEngine -productID com.google.HelloEngineTest -version 1.2 -serverURL file:///tmp/ServerResponse.plist
You'll see a lot of output. This is Update Engine letting you know what's going on, and can be useful when debugging things. It also looks cool.
The very last line of the output will look something like:
2008-09-12 11:51:01.933 HelloEngine[7055/0x0b0e] [lvl=2] main Update Succeeded
The last word from HelloEngine will be "Succeeded" or "Failed". If it Succeeded, try running /tmp/HiEngine.sh
.engine_install is required for Update Engine to function properly. You can also create .engine_preinstall and .engine_postinstall scripts to do preflight and postflight work. Outside of these scripts, Update Engine doesn't care what you have on the disk image.
The standard-out of the preinstall script gets added to the environment of the install and postinstall scripts under the environment variable KS_PREINSTALL_OUT. Likewise, the standard-out of the install script gets added to the environment of the postinstall script under the environment variable KS_INSTALL_OUT. This way you can pass information from one script phase to the next.
The scripts can be written in any language you want, but you'll want to stick to the languages (and language versions) that exist on your user's machines - they probably don't want to download and install the Object Fortran++ Scripting Bridge so that you can update your software. Likewise, if you're using Python, don't use any Python 2.5 features if you intend to update users on Tiger, who only have python 2.3.
.engine_install and the others don't even have to be a script, they can be compiled C programs if that makes sense for what you need to do.
The first argument of the script is the directory to the mount point of the disk image that Update Engine downloads. Be aware that this path can contain spaces, so do whatever string-space-quoting hygiene is necessary for your language of choice.
Inside of the script, you're welcome to do whatever you want, assuming it can be done as the user ID that the HelloEngine tool is run as. If you run it as root, then you can do most anything, please don't delete the user's /Application directory.
Here's a command for doing the same thing that's easier to put into an Xcode project:
hdiutil create -ov -imagekey zlib-level=9 -fs HFS+ -format UDZO -scrub -srcfolder $DIR $DISKIMAGENAME
In a real-world application, this can (and should) be the disk image that you give your users. This saves you from having to build, test, and deploy two different payloads for your product. The reason the scripts have the leading dot is so that they won't interfere with the Finder's presentation of the disk image when it's mounted by the user.
First, calculate the checksum:
$ openssl sha1 -binary TestApp.dmg | openssl base64This will output something like
BnKj+Bpy4KspQ4qzlkRn6EIaJ4g=After you figure out how to pronounce that, you'll need to figure out how big the file is:
$ ls -l TestApp.dmg -rw-r--r-- 1 bork bork 50405 Sep 11 18:29 TestApp.dmgEdit your ServerResponse.plist Edit the ServerResponse.plist and plug the values into the Size and Hash settings:
... <array> <dict> <key>ProductID</key> <string>com.google.HelloEngineTest</string> <key>Predicate</key> <string>Ticket.version != '2.0'</string> <key>Codebase</key> <string>file:///tmp/TestApp.dmg</string> <key>Size</key> <string>50405</string> <key>Hash</key> <string>BnKj+Bpy4KspQ4qzlkRn6EIaJ4g=</string> </dict> </array> ...In a real development environment, you'll probably want an Xcode script build phase to do this automatically for you.
Now you can use your ServerResponse.plist and your TestApp.dmg with HelloEngine to get your stuff run.
Make sure you get the path to your mounted disk from the first argument to the script, and make sure that you account for the the fact that it might contain spaces. Even if your disk image name doesn't contain spaces, the system might mount it at "/Volumes/Payload 1" if /Volumes/Payload is already in use.