One of the challenges that can crop up with deploying software packages can be repackaging packages and metapackages, especially packages that don’t have all of the installer data contained inside themselves. A good example of the latter is iLife ’11, where the installer package is small and instead acts as a master conductor to install other packages.
Another issue are applications that require multiple installs to get fully up to date. An example here would be Microsoft Office 2011, which has an installer that will install a full version of Office 2011 but then additional installer packages must be installed to get Office fully updated and patched.
To address this, you can use Packages‘ ability to add resources to a Packages-built package. See below the jump for an an example using an Office 2011 SP 3 installer package and the Office 2011 14.3.8 Update to build a unified Office 2011 SP 3 14.3.8 installer package.
1. Remove the Office 2011 installers’ application quit function.
2. Set up a new Packages project and select Raw Package.
3. In this case, I’m naming the project Microsoft Office 2011 SP 3 14.3.8
4. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)
In this example, I’m not changing any of the options from what is set by default.
5. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.
To accomplish this, I’m choosing the following options in the Settings section:
In the Post-Installation Behavior section, set On Success: to Do Nothing
In the Options section, check the box for Require admin password for installation.
6. Click on the Scripts tab in your Packages project.
7. Select your installers and drag them into the Additional Resources section of your Packages project.
In the case of my example, I’m selecting the following installers:
Office 2011 14.3.0 with Service Pack 3 Installer.pkg
Office 2011 14.3.8 Update.pkg
8. The last piece is telling the installers to run. For this, you’ll need a postinstall script. Here’s the one I’m using:
# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
# Determine working directory
install_dir=`dirname $0`
# Install Office 2011 using the specified installer packages in the working directory
/usr/sbin/installer -dumplog -verbose -pkg $install_dir/"Office 2011 14.3.0 with Service Pack 3 Installer.pkg" -target "$3"
/usr/sbin/installer -dumplog -verbose -pkg $install_dir/"Office 2011 14.3.8 Update.pkg" -target "$3"
Notice that $install_dir in the postinstall script refers to the path to the package’s working directory. That’s where Packages will be storing these installers, inside the Package-built installer’s embedded directory where it stores the items defined in the Additional Resourcessection.
The -target value is defined as “$3″ because some information is passed along by the Packages-built installer to its included scripts when those scripts are run by the installation process. (For more information, see the PackageMaker How-To available here and search on the page for $3)
In this case, -target being defined as “$3″ means that the postinstall script will install the two Office 2011 packages onto the desired drive.
The script also governs what order the installers run in, so the main Office 2011 installer runs first and the update runs next after the first job finishes. The -dumplog and -verbose flags are to help you track the progress of installation if you’re looking at the installer log.
9. Once you’ve got the postinstall script built, run the following command to make the script executable:
10. Once completed, add the postinstall script to your Packages project.
11. Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)
An additional advantage of re-packaging using Packages is that Packages by default creates flat packages, which can be signed with a Developer ID. This will allow your packages to be accepted by Gatekeeper. Signing the Packages-built flat package provides a way to accommodate Gatekeeper if you have installer packages which otherwise aren’t signed or can’t be signed.
To sign your installers, you will need to have an Apple Developer Connection membership. If you’re an ADC member, you can obtain an Developer ID Installer certificate from Apple using Xcode.
Once you have your Developer ID Installer certificate installed, you can sign the Packages-built package with the following command:
In the case of this example, I’m signing it with the following command:
The signing process will create a duplicate of the Packages-built package and sign the copy with the Developer ID Installer certificate.
To verify that your package has been signed, check your installer package to verify that it has a lock icon in the top-right corner.
Next, click the lock icon to verify that the certificate is showing up as a valid Apple Developer ID Installer certificate.
