NAME

swremove - Remove software

SYNOPSIS

No additional rationale is required under this heading.

DESCRIPTION

This utility may be used to perform the following tasks:

• Remove installed software.

• Remove software from a distribution.

• Remove software patches that have been packaged as standard software objects (filesets).

OPTIONS

No additional rationale is required under this heading.

OPERANDS

No additional rationale is required under this heading.

EXTERNAL INFLUENCES

No additional rationale is required under this heading.

EXTERNAL EFFECTS

No additional rationale is required under this heading.

EXTENDED DESCRIPTION

The remove software utility is a reversal of the install software utility. The stages, such as check remote, pre-remove customization, etc., are identical in purpose to the counterpart stage of the swinstall utility.

The swinstall utility automatically installs all filesets that a selected fileset depends on, but swremove needs to be explicitly told to remove filesets that depend on a selected fileset. This may be changed by setting autoselect_dependentstrue. The swremove utility has this default because it is easier to remove additional things if they are not wanted (that is, remove the dependencies) than it is to restore something that was erroneously removed.

Figure: Order of Remove Operations

When removing software objects, but not a bundle or subproduct that refer to those objects, the standard specifies the behavior as implementation-defined. Consensus on this matter was not achieved. An implementation may choose to remove the object, to warn the user and remove the object, or make this case an error and not remove this object. If this is an error, then the user should have a way to override this behavior.

The general consensus was that removing part of a bundle should be a warning or an error, and removing part of a subproduct should be a note or a warning. A bundle will not get installed unless explicitly specified. So, removing part of another installed bundle is not necessarily desirable. On the other hand, a subproduct may get installed as a result of a product being installed. Also, if there is a good reason why the subproduct needs to be complete (that is, there is a dependency on it), then an implementation may generate an error or warning based on dependency checks.

An example use of an unconfigure script is to perform an orderly shutdown of an application in preparation for removing it. The unconfigure script is a script or program supplied by the vendor. It is executed by the client role on each target host.

Originally, the behavior of swremove was to remove empty directories not referenced by other products. The ability to have multiple catalogs made this impractical. Since this seemed overly restrictive, the behavior with respect to directories is now implementation defined.

Note, however, that unremoved directories should still be logged.

The following is an example of rolling back a patch:

Example:

 

swremove X11.Runtime,r=1.0.8

This removes the patch X11.Runtime,r=1.0.8 and restores the saved files.

EXAMPLES

Remove the C and Pascal products as follows:

 

swremove cc pascal

Remove the C and Pascal products stored in the distribution /var/spool/sw as follows:

 

swremove -d cc pascal @ /var/spool/sw

Remove the Green and Blue subproducts from the Foo product, and write detailed messages to the stdout/stderr, as follows:

 

swremove -x verbose=2 Foo.Green Foo.Blue

Preview what would happen if the Green and Blue subproducts were removed from the Foo product as follows:

 

swremove -p Foo.Green Foo.Blue

Remove the software_selections listed in /tmp/remove.list as follows:

 

swremove -f /tmp/remove.list

EXIT STATUS

No additional rationale is required under this heading.

CONSEQUENCES OF ERRORS

No additional rationale is required under this heading.