test

Solaris 9 Installation Guide

Appendix C Additional SvR4 Packaging Requirements (Reference)

This appendix is for system administrators that need to use the custom JumpStart program or Solaris Live Upgrade to install or remove packages, especially third-party packages. Following these packaging requirements keeps a custom JumpStart installation non-interactive and keeps from modifying the currently running system so you can upgrade with Solaris Live Upgrade.

Note -

An alternate root (/) is a copy of the operating environment, not the currently running system.

Packaging Requirements Overview

For the custom JumpStart program and Solaris Live Upgrade to work properly, packages must comply with the SvR4 packaging requirements. The Application Packaging Developer's Guide provides more specific information on packaging requirements and definitions of terminology, see especially this chapter: "Advanced Package Creation Techniques" in Application Packaging Developer's Guide.

For basic information on adding and removing packages and the installation administration file, see "Managing Software (Overview)" in the System Administration Guide: Basic Administration. Also see the specific man pages.

For detailed information on the commands referenced in this appendix, see the man pages, dircmp(1), fssnap(1M), ps(1), or truss(1).

Table C-1 lists information that applies to either Solaris Live Upgrade or the custom JumpStart program.

Table C-1 Requirements Information

Installation Method 

Requirements Documented 

Solaris Live Upgrade 

Custom JumpStart program 

Custom JumpStart Program and Solaris Live Upgrade Alternate Root (/) Requirements

An alternate root (/) is a copy of the operating environment, not the currently running system. A package to be used by Live Upgrade or the custom JumpStart program must follow these requirements:

The following list explains the requirements for alternate root (/) compliance.

Differences Between $PKG_INSTALL_ROOT and $BASEDIR Overview

$PKG_INSTALL_ROOT is the location of the root (/) file system of the machine to which you are adding the package. This is set to the -R argument to the pkgadd command. For example, if the following command is invoked:


# pkgadd -R /a SUNWvxvm

Then $PKG_INSTALL_ROOT is prepended to /a during the installation of the package.

$BASEDIR points to the relocatable base directory into which relocatable package objects are installed. Only relocatable objects are installed here. Non-relocatable objects (those that have absolute paths in the pkgmap file) are always installed relative to the alternate root (/), but not relative to the $BASEDIR in effect. If a package has no relocatable objects, then the package is said to be an absolute package (or non-relocatable), and $BASEDIR is undefined and not available to package procedure scripts.

For example, suppose a package's pkgmap file has two entries:


1 f none sbin/ls 0555 root sys 3541 12322 1002918510
1 f none /sbin/ls2 0555 root sys 3541 12322 2342423332

And the pkginfo file has a specification for $BASEDIR:


BASEDIR=/opt

If this package is installed with the following command:


# pkgadd -R /a SUNWtest

Then ls is installed in /a/opt/sbin/ls, but ls2 is installed as /a/sbin/ls2.

Solaris Live Upgrade Alternate Boot Environment Compliance

When using Solaris Live Upgrade and creating a new boot environment, avoid problems by following these guidelines.

These requirements for creating, modifying and deleting files can be verified using a variety of commands. For example, the dircmp or fssnap commands can be used to verify that packages behave properly. Also, the ps command can be used for testing daemon compliance by making sure daemons are not stopped or started by the package. The truss and pkgadd commands can test runtime package installation compliance, but might not work in all situations. In the following example, the truss command strips out all read-only, non-$BASEDIR access and shows only non-read-only access to paths that do not lie within the specified alternate root (/). 


# BASEDIR=/a; export BASEDIR
# truss -t open /usr/sbin/pkgadd -R ${BASEDIR} SUNWvxvm \
2>&1 > /dev/null | grep -v O_RDONLY | grep -v \
'open("'${BASEDIR}

For detailed information on the commands referenced in this section, see the man pages, dircmp(1), fssnap(1M), ps(1), or truss(1).

Upgrade Compliance With the Custom JumpStart Program

Custom JumpStart program compliance ensures that packages can be added and removed while being part of the traditional Solaris installation utilities, which are the following:

The custom JumpStart program compliance also ensures that the package can participate in Solaris upgrades. To be custom JumpStart program compliant, a package also must follow alternate root (/) requirements that are outlined in "Custom JumpStart Program and Solaris Live Upgrade Alternate Root (/) Requirements".

To be able to use the custom JumpStart program effectively, packages must be added or removed without the user being prompted for information. To prevent user interaction, set up a new administration file with the pkgadd command -a option. The -a option defines an installation administration file to be used in place of the default administration file. Using the default file might result in the user being prompted for more information. You can create an administration file that indicates to pkgadd that it should bypass these checks and install the package with user confirmation. The following examples show how to use the pkgadd administration file.

The following is an example of an installation administration file that prevents pkgadd from prompting the user for confirmation before installing the package.

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
space=nocheck
setuid=nocheck
confiict=nocheck
action=nocheck
basedir=default

For details, see the man pages, admin(4) or pkgadd(1M).