15.2. Using GNU tar

 < Day Day Up > 

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.)


     < Day Day Up > 


    Mac OS X Tiger for Unix Geeks
    Mac OS X Tiger for Unix Geeks
    ISBN: 0596009127
    EAN: 2147483647
    Year: 2006
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net