15.1. Using PackageMaker Apple's native format for packaging and distributing software is PackageMaker. Packages created with PackageMaker have a .pkg extension. When a user double-clicks on a package, the Installer application (/Applications/Utilities) is invoked and the installation process begins. These packages are bundles that contain all of the items Installer needs. You can also use PackageMaker to create metapackages for installing multiple packages. Metapackages, or bundles, contain meta-information, files, and libraries associated with a given application. Packages can also contain multiple versions of an application; for example, both Mac OS X and Classic versions. PackageMaker documentation is available in Help Viewer, which is accessible from PackageMaker's Help option in the menu bar. The basic components of a package are: A bill of materials (.bom) binary file describing the contents of the package. You can view the contents of a bill of materials with the lsbom command. After a package is installed, you can find a copy of this file in /Library/Receipts/packagename/Contents/Archive.bom. An information file (.info) containing the information entered in the GUI application PackageMaker when the package was created. An archive file (.pax) containing the complete set of files to be installed by the package (similar to a tar archive). The file may be compressed, and have a .gz extension. A size calculation file (.sizes) listing the sizes of the compressed and uncompressed software. Resources that the installer uses during the installation, such as README files, license agreements, and pre- and post-install scripts. These resources are typically not installed; instead, they are used only during the installation process.
15.1.1. Setting up the Directory To demonstrate how to create a package, we'll create a short C program and its associated manpage. Example 15-1 shows hellow.c, and Example 15-2 shows its manpage, hellow.1. Example 15-1. The Hello, World sample program /* * hellow.c - Prints a friendly greeting. */ #include <stdio.h> int main( ) { printf("Hello, world!\n"); return 0; }
Example 15-2. The manpage for hellow.c .\" Copyright (c) 2005, O'Reilly Media, Inc. .\" .Dd April 15, 2002 .Dt HELLOW 1 .Os Mac OS X .Sh NAME .Nm hellow .Nd Greeting generator .Sh DESCRIPTION This command prints a friendly greeting.
PackageMaker expects you to set up the files using a directory structure that mirrors your intended installation. So, if you plan to install hellow into /usr/bin, and hellow.1 into /usr/share/man/man1, you must create the appropriate subdirectories under your working directory. However, you can use a makefile to create and populate those subdirectories, so to begin with, your hellow directory looks like this: $ find hellow hellow hellow/hellow.1 hellow/hellow.c hellow/Makefile
Suppose that your hellow project resides in ~/src/hellow. To keep things organized, you can create a subdirectory called stage that contains the installation directory. In that case, you'd place the hellow binary in ~/src/hellow/stage/bin and the hellow.1 manpage in ~/src/hellow/stage/share/man/man1. The makefile shown in Example 15-3 compiles hellow.c, creates the stage directory and its subdirectories, and copies the distribution files into those directories when you run the command make prep. Example 15-3. Makefile for hellow hellow: cc -o hellow hellow.c prep: hellow mkdir -p -m 755 stage/bin mkdir -p -m 755 stage/share/man/man1 cp hellow stage/bin/ cp hellow.1 stage/share/man/man1/
To get started, you need only hellow.c, hellow.1, and Makefile. When you run the command make prep, it compiles the program and copies the files to the appropriate locations in the stage directory. After running make prep, the hellow directory will look like this: $ find hellow hellow hellow/hellow hellow/hellow.1 hellow/hellow.c hellow/Makefile hellow/stage hellow/stage/bin hellow/stage/bin/hellow hellow/stage/share hellow/stage/share/man hellow/stage/share/man/man1 hellow/stage/share/man/man1/hellow.1
The next step is to launch PackageMaker and bundle up the application. 15.1.2. Creating the Package When you run PackageMaker, you must select one of the following three types of projects .
Single Package Project Used to create a package installer for a single package, which can be used as a standalone installer for the package or embedded in a metapackage or distribution.
Metapackage Project Used to create a single installer for several packages. Pre-made single packages can be embedded in a metapackage.
Distribution Project Used to create a single installer for several packages. This option, which can be used to highly customize the entire installation process, is supported only on Mac OS X 10.4 and higher. Pre-made packages can be added as installation choices by dragging them onto "distribution choices."
Since in the current example a single package is being created, you should choose Single Package Project, and set the options as appropriate for your package. Figures 15-1 through 15-6 show the settings for the hellow sample. The options are as follows:
Installer Interface tab Contains items that describe the package so the person installing the package can find its name and description (see Figure 15-1):
Title The title or name of the package.
Description A description of the package.
Show Installer Interface Editor Used to customize the installer interface's background image, Introduction blurb, Read Me, and License. This is shown in Figure 15-2.
Contents tab Contains information related to file locations and compression (see Figure 15-3):
Root This option indicates where PackageMaker can find the top-level staging directory.
Compress Archive You should leave this option enabled, since it makes the package smaller. Figure 15-1. PackageMaker's Installer Interface tab. 
Figure 15-2. PackageMaker's Installer Interface Editor 
Remove .DS_Store Files from Archives A .DS_Store file stores the information used to control how a folder is viewed in the Finder, for example, list or icon view, size of icons, etc.
Preserve Resource Forks Traditionally, Mac files consisted of two parts, a data fork and a resource fork. The data fork contains data, while the resource fork contains programming information. For more information about resource forks , see http://developer.apple.com/documentation/MacOSX/Conceptual/ SystemOverview/FileSystem/chapter_8_section_5.html. Figure 15-3. PackageMaker's Contents tab 
Configuration tab Specifies miscellaneous package options (see Figure 15-4):
Default Location This option indicates the default target location for the package.
Authentication Set this option to Root if the user needs to supply authentication to install the package. (This escalates the user's privileges to root temporarily.) Other options include None and Administrator (if the user needs only to be an Admin user, but does not need to escalate privileges). If the package will be installed into a protected directory (such as /usr), you should use Root Authorization.
Post-Install Action If this option is set to Required Restart, the system must be rebooted when the installation is finished. Other options include None, Recommended Restart, Required Logout, and Required Shutdown.
Relocatable This option allows the user to choose an alternate location for the installed files.
Root Volume Only This option requires that the user install the package on the current root volume (the volume from which Mac OS X was booted).
Follow Symbolic Links This option causes symbolic links to be followed rather than replaced with actual directories. Prior to Xcode 2.0 and Tiger, PackageMaker's default behavior was not to follow symbolic links, and since there was no interface option to control the handling of symbolic links, it was necessary to edit the Info.plist for a package and set the value for IFPkgFlagFollowLinks to Yes.
Overwrite Directory Permissions If the installer overwrites an existing file or directory, this option causes it to change the permissions to match what PackageMaker found in the staging area.
Install Fat Binaries This option supports multiple architecture binaries.
Allow Revert To Previous Version This option allows the user to install an older version of the package over a newer one. Figure 15-4. PackageMaker's Configuration tab 
Scripts tab Specifies the location of extra resources (Figure 15-5):
Extras The optional Extras directory contains scripts and other resources such as README files, that are used by the installer but aren't specified in the Installer Interface Editor. See PackageMaker's help for details. Figure 15-5. PackageMaker's Scripts tab 
PackageVersion tab Specifies detailed version information (see Figure 15-6):
Identifier A unique package name.
Get-Info string The version number to use when inspecting the package in the Finder with Get Info.
Version: A version number.
Figure 15-6. PackageMaker's Package Version tab 
After you have filled in the package settings, select Project  Build to create the .pkg file or select Project  Build and Run to create the .pkg file and install the package. After creating the .pkg file, to install it, double-click on the file and install as you would any other Mac OS X package. When you quit PackageMaker, youll be prompted to save the PackageMaker session with its currently filled in values as a .pmproj document. If you subsequently double-click your .pmproj document, PackageMaker will open with the values that were saved in the .pmproj file.  | Iceberg is provided by Stepane Sudre as an alternative to PackageMaker. (It is available at http://s.sudre.free.fr/Software/Iceberg.html.) |
|
|
