In addition to these three arguments, the ccs
receives information from custom by way of environment variables.
If the ccs receives the UPGRADE
or OLD_CUSTOM_UPGRADE keyword during installation,
some (not necessarily all)
packages of the component will be upgraded.
There is no guarantee that older versions for all packages
in the new version exist on the system.
To determine if a previous version of a given package is installed,
in the ccs script:
include a check for every reference to a file from the older package
using the following Bourne shell construct:
if [ -r filename ]
# look at the file <filename>
# choose some default instead of looking for the file
Component control scripts should exit with one of the following values:
script executed successfully.
script execution was unsuccessful and the installation or removal is aborted;
the user can choose to STOP the component.
script execution logged warnings, but the installation or removal proceeded;
the user can choose to STOP or continue the component.
script stopped processing on this component
(the component is left in the state it was in when the ccs
but continued other component installation without user intervention.
If a ccs exits with an exit value of 1 during an installation
or upgrade, the installation or upgrade will not proceed further.
However, other components that are being installed simultaneously
will continue to install.
The component is left in whatever state it was in at the
time of failure and the custom database
for the component is updated to indicate the phase that
was executing at the time of failure,
along with the keyword corrupt.
For example, a component might be left in the state of (attach, corrupt).
If a ccs exits with an exit value of 1 during a removal,
custom notifies the user and prompts the user to continue
or cancel the removal.
If the user continues the removal, the removal proceeds as if
the ccs returned a successful exit status;
if the user cancels, custom sets the state of the component
to corrupt and halts the removal process.
If the ccs exits with a value of 1,
custom attempts to recover the component from the corrupted state
by running the ccs backwards through the unsuccessful phase.
For example, if the ccs for a component installation
successfully executed through the PRE_ATTACH and
system ATTACH steps,
but returned an error code of 1 during the POST_ATTACH step,
the installation is aborted and the component status is "(ATTACH, corrupt)".
In this case, custom attempts to recover the component
by running these three operations:
undo the ATTACH system step
If all three steps execute successfully,
custom marks the component as "(LOADED, not corrupt)"
and then is ready to retry the ATTACH step.
When you write your ccs, makes sure that the removal process
(the ``UN'' steps)
can undo any actions that take place in the installation process,
even if the phase does not complete successfully.
The following limitations apply to ccs operation:
Do not use the ccs to prompt the user for input;
Do not allow the ccs to echo to stdout or stderr;
use the logging facility in the ccsSetup library instead.
In the PRE_LOAD step, make sure that the ccs
only references files contained in the SharedControl package
of the component.
Until the POST_CONFIGURE step, make sure that
the ccs only references utilities that are
either part of the component itself
or are located in the /ibin directory.
Until the POST_ATTACH step, make sure that the
ccs does not refer to its /var/opt hierarchy;
this hierarchy does not exist until the POST_ATTACH step.
The ccs must kill any running daemons
in the PRE_UNEXPORT step.
Do not assume that installations and removals will be run in
single-user mode and do not force the user to enter single-user mode.