This section shows you how to create a minimal package image for installation on an SCO OpenServer system.
The procedure takes some short cuts and omits optional package components in a tradeoff between ease of prototyping and functionality. It also provides pointers to further information where such short cuts and omissions are made.
The outcome of the procedure is a package image that can be added to an SCO OpenServer system using the pkgadd(ADM) or pkginstall(ADM) commands, or the scoadmin(ADM) application installer.
This is where you will collect all the files you want to install on the target system, the package control scripts required by pkgadd(ADM), and the information files used as input to the pkgmk(C) command. It can be located anywhere you have permission to create a directory, including your home directory.
Let's assume for this procedure that we have the following files that we want to package for installation on a target system under the /usr/local directory:
For this procedure, assume we'll use the directory /home/user1/pkgarea as our packaging area, and that it looks like this:
/home/user1/pkgarea/ pkginfo prototype other information files control scripts /src files to be packaged
This is only one possible, and very simple, arrangement. Files can, in fact, be gathered from anywhere on your development system, but in many cases using a packaging area such as the one suggested above simplifies the process of creating a package image and maintaining a backup of what was packaged for future reference.
For the purpose of this procedure, we'll assume this structure under /home/user1/pkgarea/src:
/home/user1/pkgarea/src /bin cmd1 cmd2 /man /man1 cmd1.1 cmd2.1
This directory structure mimics the directory structure that we want under the target install directory (/usr/local).
This step is not required, and might be impractical for a large number of files or even a small set of very large files. However, if all your files will be installed under a common target directory, copying them to the staging area can simplify the creation of the prototype file later in the procedure.
It is possible to gather source files during the build process from multiple locations on the system. To do this, you need to provide a custom prototype file and use appropriate arguments to the pkgproto and pkgmk commands, as we will discuss later in this procedure.
The files required to create a package are the prototype(F) and pkginfo(F) information files.
We'll create the prototype file in the next step.
The pkginfo file tells the system about your package, and must contain values for the five required installation parameters, as in this example:
PKG=testpkg NAME='Test Package' ARCH='i386' VERSION='Release 1.1' CATEGORY='application'The most important of these is PKG, which must be a unique identifier for your package (the PKG variable's value is displayed by the pkginfo(C) command as the package name). It is recommended that you define a PKG value between 3 and 9 characters, using alphanumeric characters (a-z, A-Z, 0-9) and the special characters dot (.), hyphen (-), and underscore (_) only. See pkginfo(F) for a description of these and other parameters that you can define in the pkginfo file; application-specific parameters may also be included.
No other files are required by pkgmk(C), but the particular needs of your installation may require them. [See ``Script processing'' for the sequence of script processing during software installation and removal.]
For example, if your application requires an interactive install, you'll probably need a request script to interact with the user, and a preinstall script to do any work necessary before the installation of the application's files. If any configuration needs to be done once your source files have been copied to the target system, then you'll need to provide a postinstall script that performs the configuration.
The best way to determine which files you need is to:
If we assume:
pkgproto src=/usr/local > prototype
If you need to package files from outside the packaging area (rather than having copied them into the src directory, or if you want to install files to various places on the target machine, you'll need a more complex pkgproto command.
For example, let's assume there's a very large binary that we want to put in the package and it's located on the development system at /build/build39/cmd2bld/cmd2. To include this file in the prototype file without copying it to the packaging area, we could use a pkgproto command like this:
pkgproto /build/build39/cmd2bld=/usr/local/bin src=/var/opt > prototype
Note that you can create the prototype file with any editor, you do not have to use pkgproto. See prototype(F).
For example, if our installation required postinstall and postremove scripts, and we placed these files at the top of our packaging area (where we'll execute the pkgmk command), then the following entries in the prototype file would be required to include them in the package:
i pkginfo=pkginfo i postinstall=postinstall i postremove=postremove
For testpkg, we're using only the required pkginfo file.
At this point, you may also want to add installation classes (to
selectively install groups of files based on system conditions or
user input from a request script) or make certain files
relocatable on installation.
These subjects are covered in detail in this chapter, in these sections:
``3. Placing objects into classes''
``The class action script''
``The special system classes''
``1. Selective installation''
``4. Making package objects relocatable''
cd /home/user1/pkgarea pkgmk [-o] -d path testpkg
This places a file system format package image in the directory named by path. Use the -o option to overwrite a previously created package image, if necessary.
If you plan to make the package image available for download or transfer to another system, you may want to use the pkgtrans command to convert the file system image you just created to a datastream image. A datastream image is an identical, single-file, ASCII-format version of the file system image, and so is typically easier to transfer than a file system image (which might contain many files and directories).
The example command below places a datastream image of the package in /var/spool/pkg/testpkg.ds:
pkgtrans -s path /var/spool/pkg/testpkg.ds
If you wanted to perform the reverse operation, creating a file system image from a datastream image, use a command like this example:
pkgtrans /var/spool/pkg/testpkg.ds existing_dir testpkg
The above command places a file system format image of the package under existing_dir/testpkg.
To install the ``file system image'' we created above, enter:
pkgadd -d path testpkg
To install the ``datastream image'' we created above, enter:
pkgadd -d /var/spool/pkg/testpkg.ds testpkg
[Note that when using datastreams, the name of the file containing the datastream image (testpkg.ds) is considered part of the device name. This is necessary because a datastream image can contain any number of packages or sets. A file system format image can contain only one package or set.]
pkginfo -l testpkgWhich should return the contents of the package's pkginfo file, as well as the date and time the package was installed on the target, and other information.
To list the pathnames of all files installed by a package, one per line, use the pkgchk(ADM) command:
pkgchk -v testpkg
To get a detailed listing of installed files and directories, including their contents and attributes, use:
pkgchk -l testpkg | pg
The output can reveal problems with the package information files and control scripts, such as incorrectly specified entries in the prototype file.
The pkginfo command should now return no information for the package:
# pkginfo testpkg UX:pkginfo: ERROR: information for "testpkg" was not found
See ``Quick steps to network installation'' for how to set up a network install server to offer your package for installation on remote SCO OpenServer systems.