![]() |
![]() |
| |||||||||||||||||||||||||||||||||||||||
Chapter 3Enhancing the Functionality of a PackageThis chapter describes how to create optional information files and installation scripts for a package. While Chapter 2, Building a Package discussed the minimum requirements for making a package, this chapter discusses additional functionality that you can build into a package, based on the criteria you considered when planning how to design your package (for more information, see Things to Think About Before Building a Package). This is a list of the overview information in this chapter. Creating Information Files and Installation Scripts Task MapThe table below lists and describes the optional features you can build into a package. Table 3-1 Creating Information Files and Installation Scripts Task Map
Creating Information FilesThis section discusses optional package information files. With these files you can define package dependencies, provide a copyright message, and reserve additional space on a target system. Defining Package DependenciesYou need to determine whether your package has dependencies on other packages and if any other packages depend on yours. Package dependencies and incompatibilities can be defined with two of the optional package information files, compver and depend. Delivering a compver file lets you name previous versions of your package that are compatible with the one being installed. Delivering a depend file lets you define three types of dependencies associated with your package. These dependency types are:
The depend file resolves only very basic dependencies. If your package depends upon a specific file or its contents or behavior, the depend file does not supply adequate precision. In this case, a request script or the checkinstall script should be used for detailed dependency checking. The checkinstall script is also the only script capable of cleanly halting the package installation process. Note - Be certain that your depend and compver files have entries in the prototype file. The file type should be i (for package information file). Refer to depend(4) and compver(4) for more information.
|
string string . . . |
string | Is identical to the value assigned to the VERSION parameter in the pkginfo file, for each compatible package. |
Save your changes and quit the editor.
If your package depends on the existence of other packages, other packages depend on the existence of your package, or your package is incompatible with another package, create a file named depend with your favorite text editor.
Add an entry for each dependency, using this format:
type pkg-abbrev pkg-name
(arch) version
(arch) version . . .
|
type | Defines the dependency type. Must be one of the following characters: P (prerequisite package), I (incompatible package), or R (reverse dependency). |
pkg-abbrev | Specifies the package abbreviation, such as SUNWcadap. |
pkg-name | Specifies the full package name, such as Chip designers need CAD application software to design abc chips. Runs only on xyz hardware and is installed in the usr partition. |
(arch) | Optional. Specifies the type of hardware on which the package runs. For example, sparc or x86. If you specify an architecture, you must use the parentheses as delimiters. |
version | Optional. Specifies the value assigned to the VERSION parameter in the pkginfo file. |
For more information, see depend(4).
Save your changes and quit the editor.
Complete one of the following tasks:
If you want to create additional information files and installation scripts, skip to the next task, How to Write a Copyright Message.
If you have not created your prototype file, complete the procedure How to Create a prototype File Using the pkgproto Command, and skip to Step 7.
If you have already created your prototype file, edit it and add an entry for each file you just created.
Build your package.
See How to Build a Package, if needed.
After you build the package, install it to confirm that it installs correctly and verify its integrity. Chapter 4, Verifying and Transferring a Package explains how to do this and provides step-by-step instructions on how to transfer your verified package to a distribution medium.
In this example, there are four versions of a package: 1.0, 1.1, 2.0, and the new package, 3.0, which is compatible with all the three previous versions. The compver file for the newest version might look like:
release 3.0 release 2.0 version 1.1 1.0 |
Note - The entries do not have to be in sequential order. However, they should exactly match the definition of the VERSION parameter in each package's pkginfo file. In this example, the package designers used different formats in the first three versions.
Previous Contents Index Next ![]() |