Previous section.

Systems Management: Distributed Software Administration
Copyright © 1997 The Open Group

NAME

swinstall - install software

SYNOPSIS

swinstall [-p][-r][-c catalog][-f file][-s source][-t targetfile] [-x option=value][-X options_files][software_selections]
[
@ targets]

DESCRIPTION

The swinstall utility installs software from a distribution to installed_software objects on the targets. It may also configure the software. The software is not necessarily available for use until after it has been configured.

OPTIONS

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

-c catalog

If this option is specified, then use the exported catalog structure at this path as the source of the response files.

If ask=true or ask=as_needed, the control directories in the exported catalog structure are used for both the eventual source of the response files, and the control directory where the the request scripts are executed in order to create any needed response files.

-f file

-p

-r

-s source

-t targetfile

-x option=value

-X options_file

OPERANDS

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

The utility supports software selection operands with [l=location] part of the syntax, designating the product location directory that replaces the product directory attribute when installing the software.

EXTERNAL INFLUENCES

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

Extended Options

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

allow_downdate=false

allow_incompatible=false

ask=false

autoreboot=false

autorecover=false

autorecover_product

autoselect_dependencies=as_needed

autoselect_patches=true

defer_configure=false

defer_deleting_files=false

distribution_source_directory=implementation_defined_value

enforce_dependencies=true

enforce_locatable=true

enforce_scripts=true

enforce_dsa=true

installed_software_catalog=implementation_defined_value

logfile=implementation_defined_value

loglevel=1

match_target=false

patch_save_files=true

patch_filter=*

patch_match_target=false

reinstall=false

reinstall_files=false

reinstall_files_use_cksum=true

save_modified_files=false

saved_files_directory=implementation_defined_value

select_local=true

software=

targets=

verbose=1

EXTERNAL EFFECTS

See Common Definition for Utilities .

EXTENDED DESCRIPTION

See Common Definition for Utilities for general information. There are three key phases in the swinstall utility:

  1. Selection phase

  2. Analysis phase

  3. Execution phase

Selection Phase

Multiple versions of a software product can exist from the source, distinguished by their respective "version distinguishing attributes" ( revision, architecture, and vendor_tag). If the method described in Software Specification and Logic results in an ambiguous selection, the following method is used to identify a single version:

If allow_incompatible=false, the target uname attributes are used to filter the available products to only those that are compatible with the target systems, then the version with the highest possible product revision is chosen from this filtered list. If this filtering and selection of a highest revision does not result in a unique version, then no version is selected. If allow_incompatible=true, then only the highest revision is used to try to determine a unique version. In either case, if there is still an ambiguous selection, no version is selected. See Software Compatibility .

If a software selection has dependency specifications on other software, and the option autoselect_dependencies=true, the dependency software is attempted to be automatically selected using the same method to determine a single version. This automatically selected software is then installed along with the rest of the selected software. If autoselect_dependencies=as_needed, then dependency software is attempted to be automatically selected and installed only if the dependency is not already met on the target.

If a fileset has an exrequisite on another software object, and that other software object is part of the specified software selection, either explicitly or as part of another selection, then the fileset is excluded. If two filesets have exrequisites on each other, then the behavior is implementation defined.

If more than one ancestor is defined, then this new fileset is included in the selection list during update if either or both ancestors are currently installed and the match_target option is set to true.

Unless ancestor is explicitly defined, all filesets have the default ancestor of any revision less than itself, that is,

product_tag.fileset_tag,r<revision,a=architecture,v=vendor_tag).

For swinstall, each selection added to the selected software list must satisfy the following validation checks. If any of these checks result in an event with a status of [SW_ERROR], the selection is not added to the list and the implementation defined handling procedure can be invoked.

If ask=true then execute the software request scripts for the selected software as described in the swask utility. See tagmref_swask , extended description.

Selection of software to update can be done using the match_target option. The match_target option provides a shortcut for selecting software. By default set to false. When set to true, this option causes each fileset in the distribution to be included in the selection list if:

If there are multiple filesets that match (that is, multiple revisions are installed), it is not clear which if any should be updated, and an event is generated: [SW_WARNING: SELECTION_NOT_FOUND_AMBIG].

These selections are combined with any other selections specified in the other supported means (command line operands, a software_selections file or the software extended option), and then go through the standard software selection checks.

Analysis Phase

The target role uses the file size information and checkinstall scripts obtained from the source to determine whether or not the install utility proceeds on the given target. When failures occurs in the disk space analysis and checkinstall scripts, it is implementation defined whether or not to proceed with a partial list of software selections.

If any target generates an event with a status of [SW_ERROR] during any of the analysis operations, what software is attempted to be installed is determined by the implementation defined error handling procedures.

The target role checks the following requirements:

How disk space analysis is implemented is undefined. However an implementation must account at least for the sizes of the files and control_files being installed, the additional sizes from the vendor supplied space file described in Software Definition File Format , and the additional space required from saving files if autorecover=true and if required by the implementation defined recovery process.

Most revision checks during operation of install are done fileset by fileset. When checking for newer revisions of the fileset, the product revision is checked before the fileset revision:

Execution Phase

The execution phase is the third part of the installation process, and is entered once either the selections have passed the analysis phase with no events with a status of [SW_ERROR] or if permitted by the implementation defined error handling procedures.

The relationship between the preinstall and postinstall scripts, fileset loading, and state transitions for swinstall is shown in the following list. Products are ordered by prerequisite dependencies if any. Fileset operations are also ordered by any prerequisites.

  1. Install each product:

    1. Create the installed_software catalog information for the product and its contained subproducts.

    2. Run the preinstall script for the product.

    3. Install each fileset in the product:

      1. Create the installed_software catalog information for the fileset, setting the state to transient . Also update the state of any existing fileset that is being updated or downdated to transient .

      2. Run the preinstall script for the fileset.

      3. Load the files for the fileset.

      4. Run the postinstall script for the fileset.

      5. Update the results of the scripts. Update the state of the fileset to installed . Also set the state of any existing fileset that is being updated or downdated to removed or remove the catalog information for that fileset.

    4. Run the postinstall script for the product.

    5. Once the catalog information for the last fileset in a particular product version has been removed due to update, like swremove, the catalog information for that product version should also be removed. See swremove .

  2. Install each bundle:

    1. Create the installed_software catalog information for the bundle.

  3. Configure each product (see "executing configure scripts" in tagmref_swconfig .

    Configuration is done at this point by the swinstall utility only if defer_configure=false, the target directory is /, and no filesets with the is_reboot attribute equal to true have been installed.

    1. Run the configure script for the product.

    2. Configure each fileset in the product:

      1. Run the configure script for the fileset.

      2. Update the result of the script. Update the state of the fileset to configured in the catalog for the installed_software object.

Configuration will not be executed by swinstall if the software creates a multiple version, the target directory is not /, or if the software is incompatible and allow_incompatible=false (see Software Compatibility ). In these cases, swconfig may be used.

If events with a status of [SW_ERROR] are detected during the execution phase, the swinstall utility generates the appropriate event, any log entries, and invokes the implementation defined error handling procedures. For each fileset that failed, the installed_software catalog is updated to the state corrupt.

The swinstall utility will only remove catalog information for filesets being updated if they have the same product and fileset tag in the same location by default. By specifying a supersedes attribute, catalog information for filesets being updated that have changed names (have a different tag attribute) or are otherwise superseded by new functionality will be removed as well.

EXIT STATUS

See Common Definition for Utilities .

CONSEQUENCES OF ERRORS

See Common Definition for Utilities .


Footnotes

1.
If a product is locatable (has the product=is_locatable attribute set to true), all files that have the value of product directory as the initial part of their path will be installed to a new location if one has been specified. The product directory attribute is the base directory for the files that are locatable within a specific product.

2.
It is not the intention of this Software Administration specification to define symbolic links in a manner inconsistent with POSIX.1. However, no approved POSIX standard currently contains symbolic links. This definition is a placeholder until such time as an approved standard provides the definition.

3.
In general, the order when autorecover=true is the same as normally done for successful steps, and the reverse when recovery steps are being executed.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index