For deployment purposes, custom installation packages can be used with a number of utilities to automate the process of mass
software deployment with little user interaction. In single–user environments, where user interaction may be desired, Installer
packages allow you to have a professional–looking appearance that is customized to your particular software or configuration.

Custom installation packages can be easily used to upgrade software and related files and can facilitate a customized welcome
message, read–me file, and software license to which the user must agree. Your package can also designate whether the computer
is to be restarted after software is installed.

This lesson deals with the Apple–specific package–creation utility called PackageMaker, as well as other, third–party utilities.
By the end of this lesson, you’ll know how to create, customize, and deploy custom packages to computers running Mac OS X
and Mac OS X Server.

Why Use Custom Installation Packages?

A common method for installing software is drag–install, 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 command–line tool. Installer will display the custom welcome, read–me, 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:

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.

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.

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.