< Previous PageNext Page > Hide TOC

Legacy Documentclose button

Important: The information in this document is obsolete and should not be used for new development.


About Packages

Packages are a key part of distributing and installing software with PackageMaker and Installer. The terminology and concepts described in this section will help you work effectively with packages.

Contents:

What Is a Package?
What Is a Metapackage?
File Types Created by PackageMaker
A Simple Package
The Package as a Black Box


What Is a Package?

The word “package” can have a number of different meanings. This document uses the term installation package (or simply package) to refer to the package files created by PackageMaker. These files have the following properties:

During installation, Installer creates another package file (with extension .pkg) to serve as an installation receipt, and stores it in /Library/Receipts. This document uses the term installation receipt (or simply receipt) to refer to this kind of package.

For more information on receipts, see “Installs and Upgrades.” For more information on the file types created by PackageMaker, see Table 1. For information on when you might want to edit the contents of a package directly, see “The Package as a Black Box.”

What Is a Metapackage?

A metapackage is a file that includes a list of packages (and possibly other metapackages) and any additional information needed to install them; the packages themselves, however, are not actually contained in the metapackage. Double-clicking a metapackage launches Installer. During installation for a metapackage, at the point where a user can click a button to install or upgrade the software, they also have the option of clicking a Customize button to perform a custom install.

The Custom Install pane lets the user choose from the packages contained in the metapackage (and in any metapackages it may contain). The user can also click an Easy Install button to go back to the Easy Install pane. The package creator has the option of making any package (or metapackage) in a metapackage be required, in which case the user cannot deselect that package (or metapackage). Figure 1 shows the Custom Install pane for a metapackage that is being installed on a volume named “Mac OS X version 10.3”. The metapackage contains one package (WebObjects Documentation) and one metapackage (Two Apps), which in turn contains two packages (Cool App and Mouse Pad). In this example, neither the metapackage nor any of the packages is required.

It’s a good idea to give users as much flexibility as possible, so you should generally create packages for any component of your software that a user might reasonably wish to install separately, then combine them in a metapackage.

For additional details on working with metapackages, see “Installs and Upgrades,” “Anatomy of a Metapackage,” and “Execution Order for a Complex Metapackage.”


Figure 1  A custom install for a metapackage containing one package and one metapackage

A custom install for a metapackage containing one package and one metapackage

File Types Created by PackageMaker

Table 1 lists the kinds of files PackageMaker can create. Each of these files has a specific file extension and serves a specific purpose, as described in the table.

Table 1  File types supported by PackageMaker and Installer

File type

Extension

Purpose

package

.pkg

Encapsulates software and any additional information needed to install it. Double-clicking launches Installer and starts installation. For more information, see “Anatomy of a Package.”

package definition

.pmsp

Stores information needed to create a package file. Double-clicking launches PackageMaker. As you build and test a package file, you make changes to the corresponding package definition file.

metapackage

.mpkg

Encapsulates a list of packages (and possibly metapackages) and any additional information needed to install them. Double-clicking launches Installer. For more information, see “What Is a Metapackage?.”

metapackage definition

.pmsm

Stores information needed to create a metapackage file. Double-clicking launches PackageMaker.

A Simple Package

A package is a directory, presented by the Finder as a single file, that contains all the information the Mac OS X Installer application needs to install your software. That includes the software itself, as well as files that are used only during the installation process. The software to be installed is typically stored a compressed archive, and may include application bundles, frameworks, documentation, and other kinds of files. The files used only as part of the installation process can include localized files for customizing the installation, scripts for checking the installation environment or performing other operations, and property list files created by PackageMaker to store various information about the installation.

Note: You can also create or modify a package’s property list files directly. For more information, see “Examining and Modifying Property Lists.”

Figure 2 shows the contents of a very simple installation package file.

Important: Packages created with the version of PackageMaker distributed with Mac OS X version 10.2.0 or later have the format shown in Table 1, and are compatible with versions of Installer distributed with earlier versions of Mac OS X.

To display the contents of an installation package (or any other directory displayed in the Finder as a single file), Control-click the file and choose Show Package Contents from the contextual menu.

Note: You can display the contents of a package in a Terminal window with the find command. For example, for a package named MyApplication.pkg in the current directory, type find MyApplication.pkg.

For a detailed description of the files in an installation package file, see “Anatomy of a Package.”


Figure 2  The contents of a simple installation package

The contents of a simple installation package

The Package as a Black Box

Some developers may be able to treat a package as a “black box,” created by PackageMaker and modified only through PackageMaker. In this scenario, you save a corresponding package definition (.pmsp) file for each package file you create and, if you need to change the package, you open the package definition file in PackageMaker, use the application user interface to make changes, then create a new package file.

However, you may find it convenient to modify the contents of a package file directly. For example, it can be faster to test and modify a package’s script files in the Finder or in a shell than to edit and resave the package in PackageMaker each time you modify a script. Or you might want to modify the Resources directory directly to test localized resources.

Additionally, information for some features cannot currently be supplied through the PackageMaker user interface, so if you need those features, you must modify the package’s Info.plist or Description.plist files directly. A primary example of this is the feature, added in Mac OS X version 10.3, which allows you to specify requirements for your installation package by editing the package’s property list. For more information, see “Examining and Modifying Property Lists” and “Specifying Installation Requirements.”

Some developers may also choose to modify package files directly as part of automating the build process or automating the process of distributing software. Those topics are not described in this document.

Finally, you may choose to modify packages directly as a convenience, rather than having to go back through PackageMaker each time you need to make a change. If so, be sure you consider some of the potential issues described in “Troubleshooting Packages and Installation.”



< Previous PageNext Page > Hide TOC


© 2003, 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-07-24)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.