NAME

swremove - remove software

SYNOPSIS

swremove [-d][-r][-p][-f file][-t targetfile][-x option=value]
[-X options_file][software_selections][@ targets]

DESCRIPTION

The swremove utility performs the opposite function of the install software utility or the copy software utility. It removes installed software or software stored in a distribution.

The swremove utility removes software installed at the local host or at the targets specified on the command line. It also removes software from local or remote distributions.

OPTIONS

The swremove utility supports the following options. Where there is no description, the description in Common Definition for Utilities applies.

-d

-f file

-p

-r

-t targetfile

-x option=value

-X options_file

OPERANDS

The swremove utility supports the software_selections and targets operands described in Common Definition for Utilities .

This utility need not support a target distribution in the serial format.

EXTERNAL INFLUENCES

See Common Definition for Utilities for descriptions of external influences common to all utilities.

Extended Options

The swremove utility supports the following extended options. The description in Common Definition for Utilities applies.

autoselect_dependents=false

distribution_target_directory=implementation_defined_value

enforce_dependencies=true

enforce_scripts=true

installed_software_catalog=implementation_defined_value

logfile=implementation_defined_value

loglevel=1

select_local=true

software=

targets=

verbose=1

EXTERNAL EFFECTS

See Common Definition for Utilities .

EXTENDED DESCRIPTION

See Common Definition for Utilities for general information. The swremove utility consists of three main phases.

1. Selection phase

2. Analysis phase

3. Execution phase.

Selection Phase

As opposed to swinstall, software selections apply to the target distribution or installed_software.

Each specified selection must pass the following checks. If a specification does not pass a check, the implementation defined error handling procedure is invoked.

• If the selection is not found, generate an event.
  [SW_WARNING: SW_SELECTION_NOT_FOUND]

• If the selection is not found at that product directory, generate an event.
  [SW_WARNING: SW_SELECTION_NOT_FOUND_RELATED]

• If a single version of the software is not uniquely identified from the product and product attributes specified, generate an event.
  [SW_ERROR: SW_SELECTION_NOT_FOUND_AMBIG]

Add any dependent software to the selection list if autoselect_dependents=true.

Analysis Phase

This section details the analysis phase. The analysis phase occurs before the removing of files begins, and involves executing checks to determine whether or not the removal should be attempted. No aspect of the target host environment is modified, so canceling the removal after these operations has no negative effect.

The target role makes the following checks:

• When removing installed software, execute vendor-supplied checkremove scripts to perform product-specific checks of the target. If enforce_scripts=true and the checkremove script returns an error, an event is generated and the implementation defined error handling procedure is invoked.
  [SW_ERROR: SW_CHECK_SCRIPT_ERROR]

  If the checkremove script returns an error and enforce_scripts=false, generate an event.
  [SW_WARNING: SW_CHECK_SCRIPT_ERROR]

  If the script had a warning, generate an event.
  [SW_WARNING: SW_CHECK_SCRIPT_WARNING]

  If the script has a return code of 3, generate an event and unselect the fileset (or all filesets in the product for a product level script).
  [SW_NOTE: SW_CHECK_SCRIPT_EXCLUDE]

• Verify that the dependencies are met. The swremove utility does not remove a fileset if it is required by other filesets that have not been selected for removal or cannot be removed. When enforce_dependencies=true and a non-selected fileset depends on a selected fileset, an event is generated and the implementation defined error handling procedure is invoked.
  [SW_ERROR: SW_DEPENDENCY_NOT_MET]

  When enforce_dependencies=false, generate an event.
  [SW_WARNING: SW_DEPENDENCY_NOT_MET]

If a software object has been specified for removal, and there is a bundle referring to that object that has not also been specified for removal, the behavior is implementation defined. Likewise, if a fileset or subproduct object has been specified for removal, and there is a subproduct referring to that object that has not also been specified for removal, the behavior is implementation defined.

Execution Phase

For installed_software, the sequential relationship between the unconfigure, preremove, and postremove scripts, and removing files for swremove is shown in the following list. The unconfigure scripts are only run if the target directory is /.

1. Unconfigure each product:

   If the fileset has been configured more than once, the unconfigure script must unconfigure each instance.

   1. Unconfigure each fileset in the product:

      1. Run the unconfigure script for the fileset.

      2. Update the result of the script. Update the state of the fileset in the product to installed in the database for the installed_software object.

   2. Run the unconfigure script for the product.

2. Remove each product:

   1. Run the preremove script for the product.

   2. Remove each fileset in the product:

      1. Update the state of the fileset to transient in the catalog for the installed_software object.

      2. Run the preremove script for the fileset.

      3. Remove the files for the fileset.

      4. Run the postremove script for the fileset.

      5. Update the results of the scripts. Update the state of the fileset to removed in the catalog for the installed_software object or remove the catalog information for the fileset.

   3. Run the postremove script for the product.

   4. If the catalog information has been removed for all filesets in the product, an implementation can also remove the catalog information for the product and its contained subproducts.

3. Remove each bundle:

   1. Remove the installed_software catalog information for the bundle.

4. If the catalog information has been removed for all products and bundles in the installed_software object, an implementation can also remove the catalog information for the installed_software object.

For each fileset that failed to be removed, the installed_software catalog information is updated to the state corrupt.

• Executing Pre-remove Scripts

  In this step of the execution phase, swremove executes the software preremove scripts.

  • If a preremove script returns an error and 2enforce_scripts=true", generate an event and invoke the implementation defined error handling procedures.
    [SW_ERROR: SW_PRE_SCRIPT_ERROR]

  • If the preremove script returns an error and enforce_scripts=false, generate an event.
    [SW_WARNING: SW_PRE_SCRIPT_ERROR]

  • If a preremove script returns an warning, generate an event.
    [SW_WARNING: SW_PRE_SCRIPT_WARNING]

  When swremove is removing from a distribution, no scripts must be run.

• File Removing

  In this step, swremove removes the files from the target. The target role attempts to remove each file from the target file system according to information obtained in the software_selections sent.

  If swremove cannot remove a file (either because the file is busy [ETXTBSY], or for some other reason), the file name and the reason are logged so an administrator can take corrective action.
  [SW_WARNING: SW_FILE_NOT_REMOVABLE]

  If a filename is a symbolic link, the target is not removed. To achieve this behavior, the swremove utility handles symbolic links according to these rules:

  • If a file was recorded in the catalog as a symbolic link to another file, and it is still a symbolic link on the file system, remove the symbolic link, but do not remove the target file.

  • If a file was recorded in the catalog as a file, but exists as a symbolic link on the file system, remove the symbolic link, but do not remove the target file.

  • If the pathname to the file includes a symbolic link, this path is followed and the correct file is removed.

  All files that are targets of symbolic links are removed when the fileset to which they belong is removed.

• Executing Post-remove Scripts

  In this step of the execution phase, swremove executes software postremove scripts.

  • If a postremove script returns an error and enforce_scripts=true, generate an event and invoke the implementation defined error handling procedures.
    [SW_ERROR: SW_POST_SCRIPT_ERROR]

  • If the postremove script returns an error and enforce_scripts=false, generate an event.
    [SW_WARNING: SW_POST_SCRIPT_ERROR]

  • If a postremove script returns an warning, generate an event.
    [SW_WARNING: SW_POST_SCRIPT_WARNING]

• Kernel Reconfiguration

  If the is_kernel attribute of the fileset is true, then a warning message to rebuild the kernel is displayed and also recorded in the log file. However, swremove does not modify any of the kernel generation files.

• Removing from a Distribution

  The list of operations is simpler for removing filesets from a distribution than for installed_software.

  1. Remove each product:

     1. Remove each fileset in the product:

        1. Update the state of the fileset to transient in the catalog for the distribution.

        2. Remove the files for the fileset.

        3. Update the state of the fileset to removed in the catalog for the distribution or remove the catalog information for the fileset.

     2. If the catalog information has been removed for all filesets in the product, an implementation can also remove the catalog information for the product and its contained subproducts. For each fileset that failed to be removed, the distribution catalog information is updated to the state corrupt .

  2. Remove each bundle:

     1. Remove the distribution catalog information for the bundle.

  3. If the catalog information has been removed for all products and bundles in the distribution object, an implementation can also remove the catalog information for the distribution object.

• Patches

  Removal of the base fileset of a patch fileset via swremove will also result in removal of all patches to that fileset. Likewise when a particular base fileset is overwritten during a swinstall update operation, all patches for that base are removed as well. Saved rollback data is also removed when the base fileset to which it applies is updated or removed from the system.

  Removal of a patch automatically rolls back previous files, unless the rollback has been disabled as described for tagmref_swinstall or tagmref_swmodify , or unless the base fileset is also being removed or updated. The patch fileset has the value of the saved_files_directory stored as an attribute, so that it can correctly find those files even if multiple saved_files_directory values have been used for various filesets.

  Only patches with the state applied can be rolled back. If a patch with a state of committed or superseded is attempted to be removed, generate an event. If the files for a patch do not exist in the saved_files_directory, or that directory no longer exists, generate an event.
  [SW_ERROR:SW_DEPENDENCY_NOT_MET]

  An installed patch that has been superseded may not be rolled back unless the superseding patch is also rolled back.

EXIT STATUS

See Common Definition for Utilities .

CONSEQUENCES OF ERRORS

See Common Definition for Utilities .