Why Use Custom Installation Packages?

A common method for installing software is draginstall, in which the application and associated files are copied from the distribution media to the target volume. Although this method is easy and works well when the application files need to be copied to only one or two places in the file system, it is not the most flexible method of installing software. A custom installation package is a better choice because you are able to do the following:

• Verify that a certain version of the operating system is already installed

• Verify that certain components are already in the system

• Start or stop processes

• Put software in multiple locations throughout the system

Custom packages can come in a few varieties, as discussed below.

About Installation Packages

An installation package is a collection of compressed files and other information used to install software onto a computer. The contents of an installation package are contained within a single bundle, which has the extension .pkg. The package is created by using the utility PackageMaker, which can be found in /Developer/Applications/Utilities if the Xcode Developer Tools were installed. The Finder displays the package bundle as a single file, but it is actually a special folder that contains all the files needed for a custom install.

Note

Although the Mac OS X Server Administration Tools disc includes a copy of PackageMaker, you should install the Xcode Developer Tools to get the most recent version of PackageMaker. The Xcode installation package is available from the Apple Developer Connection (http://developer.apple.com).

Installer packages are installed either by the Installer application or by the installer commandline tool. Installer will display the custom welcome, readme, and license information; place the software in its designated locations; and run scripts designated for the installation.

About Metapackages

Metapackages allow you to present multiple packages to the user as a single installation package. A metapackage doesn't install files itself; instead it references other packages to perform the actual installations. You can designate each package within the metapackage as optional or required, allowing your users the flexibility to choose what they want to install.

Just as with installation packages, the user installing a metapackage clicks only one bundle in the Finder and is presented with the same Installer interface, but there is one exception. With metapackages, the user is offered a Customize button, which, if clicked, will display a list of each of the packages being installed, as well as check boxes to enable or disable each package.

Metapackages can be useful if you have files that are common to all users but still allow groups to have their own collections of additional files. For example, you could create a separate package that contains both department files and the files for all users. However, as soon as one of the files used by everyone changes, you need to re-create every department package. The solution, as shown in the following figure, is to create separate metapackages for each department, each also containing a common package for all users. This way, your users will have a single installation experience, but if a common file changes, only the common package has to be updated.

Metapackages are also useful for large software packages, when you have a large set of files you'd like to distribute, but only certain files will be updated. You could create a metapackage that refers to three separate packages:

1. The main application This package might come directly from the vendor; or, if you were repackaging it, it would be updated with every revision of the application.

2. Configuration presets This package might include default preferences for all of your users, as well as license code information that you'd rather distribute directly in a file rather than having to type a license code at every workstation. This package would rarely need to be updated.

3. Plug-ins and support files This package could contain third-party plug-ins and other support files. It would rarely need to be updated. If additional plug-ins were needed later, you would simply add another package to your metapackage.