Advanced Search

Log In | Not a Member?

Contact ADC

< Previous PageNext Page > Hide TOC

Create the Component Package

After you have created the package project directory, you use PackageMaker (/Developer/Applications/Utilities) to create the component package project file.

To create a component package in PackageMaker:

1. Create a single package project.

2. Enter the package’s title and description.

3. Identify the directory that contains the component’s files (for example, the component directory in the package project directory).

4. Edit the component directory’s ownership and access permissions settings using the File Permissions editor.

   The files that the Installer application places on the installation host have the ownership and access permissions specified in the component files in the package. Therefore, you must set up the owner and access permissions of component files appropriately before generating the installation package; otherwise, users may have difficulty manipulating those files after they are installed. In most cases, the owner should be root and the group admin. Use the permissions recommended in the File Permissions editor.

   Overwriting directory access permissions: The Installer application assigns access permissions to directories that don’t exist on the installation volume but are part of a product’s structure. (These directories are specified in the component directory when you created the component package.) When a directory that’s part of the component hierarchy already exists on the installation volume, its permissions are modified only if the package specifies that directory permissions must be overwritten. Because modifying the permissions of existing directories in Mac OS X—especially standard directories in the local and system domain—may impair the normal operation of the installation host, you should not generally have packages overwrite directory permissions. However, components that use an internal hierarchy that doesn’t include Mac OS X standard directories may need to overwrite the access permissions of their internal directories to ensure a successful install.

   To illustrate this situation, analyze the structure of the Nificky component directory, shown here.

   component/

   Nificky/

   Nificky.app

   ReadMe.rtf

   The installation destination for the Nificky application component is /Applications. Therefore, after the component is installed, the Applications directory on the installation volume contains the Nificky directory, which itself contains the Nificky.app file package and the ReadMe.rtf file. But, if Applications/Nificky already exists on the volume and its access permissions do not allow modification, the install fails. Specifying that the installation package for the Nificky application overwrite directory access permissions ensures that the Installer application modifies the permissions on Applications/Nificky to allow it to place files within the directory. The access permissions of the Applications directory are untouched.

   Important: Never include Mac OS X standard directories inside a component’s hierarchy. That is, do not reflect any standard part of the Mac OS X file system (in any of the file system domains) inside your component’s structure.

5. Set the installation destination for the component, and specify an appropriate authentication level and postinstallation process action, if needed.

   Installing into the user’s home directory: One way to place files into a user’s home directory is to specify /Users/Shared as the installation destination and use an install operation to move the product files into the current user’s home directory (specified by the $HOME environment variable). See “Specifying Install Operations” for details.

6. Identify the subdirectory in the project directory that contains executable files that specify installation requirements or install operations, if needed.

7. Set the package identifier and version number.

   A package’s identifier and version number help the Installer application determine the best way to update a product’s files during an install on a system on which the package has already been installed. You must set these two package properties for every package you create.

   For applications and frameworks, use the bundle identifier (CFBundleIdentifier) specified in their Info.plist files as a starting point. For example, if the bundle ID of an application is com.mycompany.Levon, the package identifier should be com.mycompany.Levon.pkg. Keep in mind that the package identifier must be unique. (For detailed information on the CFBundleIdentifier and other Info.plist keys, see Runtime Configuration Guidelines.)

   Note: The Info.plist file is located in the Contents directory of application and plug-in file packages (use the Finder Show Package Contents command to reveal the contents of file packages). In a framework, the Info.plist file is located in the Resources directory.

   The package version for application, framework, and plug-in component packages should be the value for the CFBundleShortVersionString property of the component they contain. In framework component packages, use the value for the CFBundleVersion property. For other component types, choose an appropriate package identifier and package version number.

   Important: Installer does not use the identifier and version information specified in the Info.plist files of a package’s payload.

After you’ve defined a package, use the PackageMaker Build command to generate the component package (.pkg) file. You can also save the package project file in the project directory for future use.

< Previous PageNext Page > Hide TOC

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.

	Get information on Apple products. Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice