 |  |
6.4. Packaging Tools
The following packaging options come with Mac OS X.
- PackageMaker
- Found in /Developer/Applications, PackageMaker can be used to create packages that are bundles consisting of all the items that the Mac OS X Installer (/Applications/Utilities) needs to perform an installation. PackageMaker can also create metapackages, which can be used to install multiple packages at the same time.
- gnutar and gzip
- The Unix tape archive tools (tar and gnutar; gnutar is preferred because it can handle longer pathnames) are used to bundle the directories and resources for distribution. GNU Zip (gzip) is used to compress the tar archives to make file sizes as small as possible. Using these tools is generally the simplest way to copy a collection of files from one machine to another.
- Disk Copy
- One of the easiest ways to distribute an application is to use Disk Copy (/Applications/Utilities) to create a disk image. You can use Disk Copy to create a double-clickable archive, which mounts as a disk image on the user's desktop. From there, the user can choose to mount the disk image each time the application is run, copy the application to the hard drive (usually to the /Applications directory), or burn the image to a CD.
Each of these tools will be discussed separately in the sections that follow.
6.4.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 the 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; typically, both Mac OS X and Classic versions.
PackageMaker documentation is available in the Help Viewer at /Developer/Documentation/DeveloperTools/PackageMaker/PackageMaker.help.
The basic components of a package are:
-
A bill of materials (.bom) binary file that describes the contents of the package. You can view the contents of a bill of materials with the lsbom command.
-
An information file (.info) that contains the information entered in the GUI application PackageMaker when the package was created.
-
An archive file (.pax) that contains the complete set of files to be installed by the package. (This archive file can be compressed, giving it a .pax.gz extension.) This is similar to a tar archive.
-
A size calculation file (.sizes) that lists 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.
6.4.1.1. Setting up the directory
To demonstrate how to create a package, we'll use the hellow.c and hellow.1 examples shown earlier in this chapter (in Example 6-1 and Example 6-2).
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'll need to create the appropriate subdirectories under your working directory.
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 want to 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 6-4 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 6-4. makefile for hellow
hellow:
cc -o hellow hellow.c
prep: hellow
mkdir -p stage/bin
mkdir -p stage/share/man/man1
cp hellow stage/bin/
cp hellow.1 stage/share/man/man1/WARNING: The directories you create in the stage directory should have the same permissions as the directories into which you are installing the package. If your umask is set so that the permissions are not right, use chmod in your makefile to correct the permissions after you create the staging directories.
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 their locations in the stage directory. After that, you're ready to launch PackageMaker and bundle up the application.
6.4.1.2. Creating the package
Run PackageMaker and set the options as appropriate for your package. Figure 6-2 through Figure 6-6 show the settings for the hellow sample. The options are as follows:
- Description tab
-
Contains items that describe the package so the person installing the
package can find its name and version.
- Title
- The title, or name, of the package.
- Version
- The version number of the package.
- Description
- A description of the package.
- Delete Warning
-
A custom warning message to display when a user removes the package.
Mac OS X does not have a utility to uninstall a package, though.
Figure 6-2. PackageMaker's Description tab
- Files tab
-
Contains information related to file locations and compression.
- 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 6-3. PackageMaker's Files tab
- Resources tab
-
Specifies the location of extra resources.
- Resources
-
The Resources directory contains files, such as
README files, that are used by the installer but
aren't installed on the disk. See PackageMaker help
for details.
Figure 6-4. PackageMaker's Resources tab
- Info tab
-
Specifies miscellaneous package options.
- Default Location
- This option indicates the default target location for the package.
- Restart Action
- If this option is set to Required Restart, the system must be rebooted when the installation is finished. Other options include No Restart Required, Recommended Restart, and Shutdown Required.
- Authorization Action
- Set this option to Root Authorization if the user needs to supply authentication to install the package. (This escalates the user's privileges to root temporarily.) Other options include No Authorization Required and Admin Authorization (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.
- Allows Back Rev.
- This option allows the user to install an older version of the package over a newer one.
- Install Fat
- This option supports multiple architecture binaries.
- Relocatable
- This option allows the user to choose an alternate location for the installed files.
- Required
- This option implies that certain packages (when installed as part of a larger install) are required.
- Root Volume Only
- This option requires that the user install the package on the current root volume (the volume from which you booted Mac OS X).
- Update Installed Languages Only
- When you update a package, this option will only update the currently installed localization projects.
- Overwrite Permissions
-
If the installer overwrites an existing file or directory, this
option will cause it to change the permissions to match what
PackageMaker found in the staging area.
Figure 6-5. PackageMaker's Info tab
- Version tab
-
Specifies detailed version information.
- Display name
- The name of the package to use when reporting its version
- Identifier
- A unique package name
- Get-Info string
- The version number to use when inspecting the package in the Finder with Get Info
- Short version
- An abbreviated version number
- Version: Major
- A major version number (the 1 in 1.0)
- Version: Minor
-
A minor version number (the 0 in 1.0)
Figure 6-6. PackageMaker's Version tab
After you have filled in the package settings, select Tools
Create Package to create the
.pkg file. To install it, double-click on the
file and install as you would any other Mac OS X
package.
6.4.2. Using GNU tar
For Unix-based software that does not involve resource forks or creator types, gnutar and gzip can be used to create a .tar.gz or .tgz tarball. This type of tarball preserves paths, permissions, and symbolic links. It also supports authentication and compresses well. Tools to uncompress the tarball are available for many platforms.
The automated creation of such a tarball can be worked into the same makefile that is used to build the software. Preservation of resource forks is tricky, but possible, in this method. For example, the following command preserves Macintosh resource forks (where foo/ is a directory):
gnutar -pczf foo.tgz foo/
Every good tarball has a single top-level directory that contains everything else. You should not create tarballs that dump their contents into the current directory. To install software packaged this way, you can use the following command:
gnutar -pxzf foo.tgz
This simply unpacks the tarball into the file and directory structure that existed prior to packaging. Basically, it reverses the packing step. This method can be used to simply write files to the appropriate places on the system, such as /usr/local/bin, /usr/local/lib, /usr/local/man, /usr/local/include, and so on.
WARNING: When creating packages, you should keep your package contents out of directories such as /etc, /usr/bin, /usr/lib, /usr/include, or any top-level directory reserved for the operating system, since you have no way of knowing what a future software update or Mac OS X upgrade will include. For example, the Fink project stays out of Mac OS X's way by keeping most of its files in /sw. We suggest that you use /usr/local for the packages that you compile.
This packaging method can also be arranged so that the unpacking is done first in a temporary directory. The user can then run an install script that relocates the package contents to their final destination. This approach is usually preferred, since the install script could be designed to do some basic checking of dependencies, the existence of destination directories, the recataloging of libraries, etc. You could also include an uninstall script with your distribution.
The disadvantages of the tarball method of distributing software are:
-
There is no built-in mechanism for keeping track of which files go where.
-
There is no built-in method for uninstalling the software.
-
It is difficult to list what software is installed and how the installed files depend on each other or on other libraries.
-
There is no checking of dependencies and prerequisite software prior to the installation.
These tasks could be built into install and uninstall scripts, but there is no inherently uniform, consistent, and coherent method for accomplishing these tasks when multiple software packages are installed in this manner. Fortunately, more sophisticated methods of packaging, distributing, and maintaining software on Unix systems have been devised, such as Red Hat's RPM, Debian's dpkg, and Apple's PackageMaker.
6.4.3. Disk Images
Many applications in Mac OS X do not require a special installer. Often, they can be installed by simply dragging the application's folder or icon to a convenient location in the directory structure, usually the /Applications folder. Applications that are distributed this way are typically packaged as a disk image. A disk image is a file that, when double-clicked, creates a virtual volume that is mounted on the user's desktop, as shown in Figure 6-7.
Figure 6-7. A disk image and its mounted volume
Inside Applications
Actually, an application is a folder with the extension .app, which is typically hidden from the user. This folder contains all of the application's resources. To view the contents of an application bundle, Control-click on the application icon and select Show Package Contents from the pop-up menu. This will open the application's Contents folder in the Finder.
TIP: You can turn a Java application into a .app with MRJAppBuilder (/Developer/Applications). Since Mac OS X comes with Java, you can place your Java application on a disk image, secure in the knowledge that any Mac OS X user can double-click on the application to launch it.
Disk images can be created either using Disk Copy (/Applications/Utilities) or via the command line (described later). There are two types of disk images. One is a dual fork disk image with an .img extension, and the other is a single fork disk image with a .dmg extension. A dual fork disk image requires additional (MacBinary) encoding in order for it to be transferred across networks. The single fork version is preferred for distributing software in Mac OS X, as it requires no additional encoding.
The Unix command df will reveal a disk image as
a mounted volume, and it will appear in the
/Volumes directory. When you are done with the
mounted volume, it can be ejected to unmount it. This is accomplished
by clicking on the volume (in Figure 6-7, the
mounted volume is named Fink 0.4.0a Installer) to select it and going
to File Eject (
-E).
You could also drag the mounted volume to the Trash.
TIP: If you've used earlier versions of the Mac OS, you're probably familiar with the Put Away command (
6.4.3.1. Creating a disk image with Disk Copy
To create a disk image using Disk Copy, perform the following steps:
-
Launch Disk Copy (/Applications/Utilities).
-
Select File
New Blank Image.
Disk Copy prompts you for a name, location, size (the maximum size is
limited by available disk space), volume name, format, and encryption
options, as shown in Figure 6-8. If you choose to
enable encryption, Disk Copy will prompt you for a passphrase.
Figure 6-8. Creating a new blank image with Disk Copy
-
Name the new image "My Disk Image" and choose the Desktop as the location. Set the Volume Name to "SampleVol" and click Create. The new image will be created as My Disk Image.dmg and mounted as SampleVol.
-
Double-click on the disk icon to open the empty volume in a Finder window, as shown in Figure 6-9.
Figure 6-9. A blank disk image, ready to be loaded up with files
-
Select File
New Finder Window (or
-N) to open a new Finder window, where
you can select the files you want to place in the disk image, as
shown in Figure 6-10.
Figure 6-10. Copying a file to the disk image
-
To copy the files to the mounted volume, select and then drag the items into the empty SampleVol window.
-
Once you've placed the files into the disk image, eject this disk (
-E, or drag SampleVol
to the Trash).
-
Return to the Disk Copy application, select File
Convert Image, locate the disk image file in the Convert Image
window, and click on the Convert button, as shown in Figure 6-11.
Figure 6-11. Choosing the image to convert
-
The Convert Image window will change. Enter either a new name or the same name in the Save As field, and then select read-only from the Image Format pull-down menu, as shown in Figure 6-12. (You can also compress the disk image from this selection.)
Figure 6-12. Converting an image
-
Click the Convert button. If you've given the disk image the same filename as the original image you created, an alert window will appear, asking you to confirm whether or not you want to replace the older file with the new one. Click Replace to finish the process.
6.4.3.2. Creating a disk image from the command line
The following example illustrates how to create a disk image at the command line.
WARNING: To avoid accidentally wiping out a physical disk, make sure you are logged in as an unprivileged user when you use these commands. Do not log in as root or use sudo.
-
Change (cd ) to the directory where you want to create the disk image:
cd ~/Documents
-
Create the disk image of a given size (10 MB in this example) using hdiutil:
hdiutil create -megabytes 10 Sample.dmg -layout NONE
-
Associate the disk image with a device without actually mounting it:
hdid -nomount Sample.dmg
This attaches the image to the system under an unused device, such as /dev/disk2. (hdid will report the device, or you can use hdiutil info to see all of the attached images.)
-
Format the disk as HFS+ with newfs_hfs. (Replace REAL_DEVICE with the actual device used, such as /dev/disk2.) Be careful with this command--if you run it on your hard drive, it could wipe out your disk.
newfs_hfs -v SampleVol /dev/REAL_DEVICE
-
Detach the newly formatted device:
hdiutil eject /dev/REAL_DEVICE
-
Mount the writable image as a volume. Since you named it SampleVol when you issued the newfs_hfs command, it will appear on the desktop as SampleVol:
hdid Sample.dmg
-
Use the Finder or command-line tools to write to the volume SampleVol. It will appear on your desktop and will be available in /Volumes/SampleVol.
-
When you are done writing to the volume, you can eject it in the Finder, using one of the methods described earlier.
-
Copy the disk image to a compressed, read-only image named Ready4Dist.dmg:
hdiutil convert -format UDZO Sample.dmg -o Ready4Dist.dmg
Whenever you want to mount this volume again, you can double-click the file Ready4Dist.dmg in the finder. Note that the writable disk image Sample.dmg is not destroyed in this process.
There were several names involved with that last example, so here's a refresher:
- Sample.dmg
- A writable 10 MB disk image created in Step 2.
- /dev/disk2, /dev/REAL_DEVICE
- The system device under which you attached Sample.dmg in Step 3.
- SampleVol
- The volume name you gave to the disk image when you formatted this in Step 4.
- Ready4Dist.dmg
- A read-only, compressed copy of Sample.dmg, created in Step 9. Since it's a copy, it has the same volume name as Sample.dmg: SampleVol.
6.4.4. Distributing Your Image
Once you've created a disk image, you can share it
with the world. Put the image up on a web server or FTP server for
others to enjoy, share it on your iDisk, or burn it to a CD using
Disk Copy (select File Burn
Image).
|  | |
| 6.3. GNU-Darwin |  | III. Beyond the User Space |
Copyright © 2003 O'Reilly & Associates. All rights reserved.