The central part of a managed install is the installation package, which contains your product and installation information. The following sections describe installation packages and the various types of packages you may need to create when developing a managed install for a product.
What Is a Package?
Component Packages
Metapackages
Distribution Packages
An installation package (also known as a package) is a file package (a directory that appears in the Finder as a single file) created using the PackageMaker application (/Developer/Applications/Utilities). Packages contain a product or product component—the package’s payload—to be installed on a computer, and install configuration information that determines where and how the product is installed.
Note: Application executables are usually enclosed in a bundle: a structured directory hierarchy that contains resources needed by the application, such as images and localized strings. Because these bundles are normally file packages, the term application package refers to an application bundle that the Finder displays as a single file. However, in this document the term package refers to an installation package, not an application package. For detailed information on Mac OS X bundles, see Bundle Programming Guide.
Packages have the extension .pkg or .mpkg. When a user double-clicks a package in a Finder window, the Installer application opens the package and walks the user through the installation process.
A package can specify details about four aspects of the package itself and its payload:
Product information:
Title
Description
Welcome file
Read Me file
License file
Conclusion file
Package properties:
Package identifier
Package version number
Resource fork processing
Installation properties:
System requirements
Volume requirements
Authentication requirement
Allowance for choosing an installation volume other than the boot volume
Installation destination on the installation volume
Relocation consent (the ability user may have to change the installation destination)
Revert consent
Directory-permissions overwrite
Postinstallation process action
Install operations:
Preflight
Preinstall/Preupgrade
Postinstall/Postupgrade
Postflight
A complex product, such as the Levon product introduced in “Overview of Software Delivery,” is made up of distinct components. Except for single-component products, component packages are used in conjunction with metapackages or distribution packages (described later in this chapter) to create an install experience. Specifically, component packages:
Are the basis for the mechanism that allows you to provide users a way to specify which components to install (for example, a user may not want to install a product’s tutorial files)
Let you identify required components (which must be installed) and specify the locations of components to be installed at specific locations on the installation volume
Allow you to specify system and volume requirements for the component using executable files (see “Specifying System and Volume Requirements in Pre-Tiger Systems”)
Component packages have the extension .pkg. Each component package contains a single product component and specifies product information, package properties, installation properties, and install operations.
Note: During an install of a metapackage (described in “Metapackages”), the product information for the contained component packages is not used or shown to the user. The product information for a component package is used only when installing the component package by itself, with no enclosing metapackage. Therefore, product information on a component package is generally used only by someone creating a metapackage or a distribution package containing that component package as they define the product information for the containing package.
Component packages can be installed on their own or as part of the install of a multicomponent product. After the payload of a component package is installed, Installer places a receipt in the /Library/Receipts directory of the installation volume. An installation receipt is a token that Installer uses to determine whether a package has already been installed on a system. As long as the receipt is present, subsequent installs of packages using the same package filename on the same volume are processed as upgrades.
A metapackage is an installation package that contains other installation packages. The enclosed packages can be component packages or metapackages (but not distribution packages).
Metapackages allow you to define a simple install experience for a multicomponent product. When users open a metapackage with the Installer application, they can choose to install only the components they need. Each enclosed package becomes an install choice. For example, if a product includes a tutorial-files component that the user performing the install doesn’t need, they can choose not to install that component.
Metapackages have the extension .mpkg. Table 4-1 shows what aspects of a metapackage and the packages (component packages and other metapackages) it contains are used in the installation process.
Product information | Package properties | Installation properties | Install operations | |
|---|---|---|---|---|
Metapackage |
|
|
|
|
Contained packages |
|
|
|
|
Table 4-1 indicates that the containing metapackage specifies package properties, installation properties, and specify install operations. However, the only aspect of the metapackage used in the installation process is its product information. Conversely, for the packages the metapackage contains, all aspects except product information are used in the installation process.
A distribution package is a metapackage that specifies both product and installation information for a product. Distribution packages provide more sophisticated facilities to tailor the installation process. The major features distribution packages provide are:
Definition of the entire install experience in one place instead of having it spread out through several component packages
Definition of system and volume requirements using a requirements editor instead of executables
Install choices can contain more than one component package
Users can choose an installation destination for each install choice instead of for the entire install
Installer loads a distribution package for a multicomponent product with many component packages (and presents the user with the install experience it specifies) faster than a metapackage containing the same product
The central part of a distribution package is the distribution script. This is a JavaScript-based script file that contains all the information that defines an install experience. When you create a distribution package using PackageMaker, the package’s distribution script is created for you.
Distribution packages differ from metapackages in these areas:
They can be installed only on computers running Mac OS X v10.4 (Tiger) and later.
They must contain only component packages, not metapackages or distribution packages.
Installer ignores installation properties specified in the contained component packages (installation properties are specified by the distribution script).
Table 4-2 shows what aspects of a distribution package and the component packages it contains are used in the installation process.
Product information | Package properties | Installation properties | Install operations | |
|---|---|---|---|---|
Distribution package |
|
| ||
Contained packages |
|
|
|
|
Table 4-2 indicates that a distribution package specifies only product information and installation properties, and both aspects are used in the installation process. The contained packages may specify all package aspects, but only their package properties and install operations contribute to the installation process.
Important: The system and volume requirements for a distribution package must reflect all the system and volume requirements of each of the component packages the distribution package contains.
Last updated: 2006-07-24