Creating and Deploying Packages
- Why Use Custom Installation Packages?
- Looking Inside a Package
- Creating Packages
- Lesson Review
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
Time
This lesson takes about 2 hours to complete.
Goals
Create and deliver custom installation packages for Mac OS X and Mac OS X Server
Describe the differences between packages and metapackages
For deployment purposes, custom installation packages can be used with a number of utilities to automate the process of mass software deployment with little user interaction. In single–user environments, where user interaction may be desired, Installer packages allow you to have a professional–looking appearance that is customized to your particular software or configuration.
Custom installation packages can be easily used to upgrade software and related files and can facilitate a customized welcome message, read–me file, and software license to which the user must agree. Your package can also designate whether the computer is to be restarted after software is installed.
This lesson deals with the Apple–specific package–creation utility called PackageMaker, as well as other, third–party utilities. By the end of this lesson, you’ll know how to create, customize, and deploy custom packages to computers running Mac OS X and Mac OS X Server.
Why Use Custom Installation Packages?
A common method for installing software is drag–install, in which the application and associated files are copied from the distribution media to the target volume. Although this method is easy and works well when the application files need to be copied to only one or two places in the file system, it is not the most flexible method of installing software. A custom installation package is a better choice because you are able to do the following:
- Verify that a certain version of the operating system is already installed
- Verify that certain components are already in the system
- Start or stop processes
- Put software in multiple locations throughout the system
Custom packages can come in a few varieties, as discussed below.
About Installation Packages
An installation package is a collection of compressed files and other information used to install software onto a computer. The contents of an installation package are contained within a single bundle, which has the extension .pkg. The package is created by using the utility PackageMaker, which can be found in /Developer/Applications/Utilities if the Xcode Developer Tools were installed. The Finder displays the package bundle as a single file, but it is actually a special folder that contains all the files needed for a custom install.
Installer packages are installed either by the Installer application or by the installer command–line tool. Installer will display the custom welcome, read–me, and license information; place the software in its designated locations; and run scripts designated for the installation.
About Metapackages
Metapackages allow you to present multiple packages to the user as a single installation package. A metapackage doesn’t install files itself; instead it references other packages to perform the actual installations. You can designate each package within the metapackage as optional or required, allowing your users the flexibility to choose what they want to install.
Just as with installation packages, the user installing a metapackage clicks only one bundle in the Finder and is presented with the same Installer interface, but there is one exception. With metapackages, the user is offered a Customize button, which, if clicked, will display a list of each of the packages being installed, as well as check boxes to enable or disable each package.
Metapackages can be useful if you have files that are common to all users but still allow groups to have their own collections of additional files. For example, you could create a separate package that contains both department files and the files for all users. However, as soon as one of the files used by everyone changes, you need to re-create every department package. The solution, as shown in the following figure, is to create separate metapackages for each department, each also containing a common package for all users. This way, your users will have a single installation experience, but if a common file changes, only the common package has to be updated.
)
Metapackages are also useful for large software packages, when you have a large set of files you’d like to distribute, but only certain files will be updated. You could create a metapackage that refers to three separate packages:
-
The main application— This package might come directly from the vendor; or, if you were repackaging it, it would be updated with every revision of the application.
-
Configuration presets— This package might include default preferences for all of your users, as well as license code information that you’d rather distribute directly in a file rather than having to type a license code at every workstation. This package would rarely need to be updated.
-
Plug-ins and support files— This package could contain third-party plug-ins and other support files. It would rarely need to be updated. If additional plug-ins were needed later, you would simply add another package to your metapackage.