Previous section.

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

Background Information


Scope and Purpose

This Appendix provides background information on the approach adopted by the developers of the 1387.2 Standard, and the reasons why it was specified in the way it is. It is hoped this information will be helpful to both implementors and users.

A number of areas are not covered in the 1387.2 Standard. A few things (such as physical media) are truly outside the scope of the Standard. However, some things are listed as either undefined or unspecified.

The requirements for all POSIX.2 utilities and all the file system features of POSIX.1 were significant issues in formulating this Standard. It was asserted that the underlying operating system need not be fully POSIX.1 or POSIX.2 conformant. With the requirement left as it is, implementation on such systems as DOS, OS/2, MVS, VMS, etc., is feasible.

Implementers of this Standard should provide some guidance to those who write scripts which will be packaged in distributions. It is actually those scripts that have significant dependencies on the features of the underlying operating system. Assured portability of scripts is not possible without assurance of an interpreter and utilities. By allowing other interpreters, some concession has been made to assist in managing existing software in the real world. The best portability assumption is that the checkinstall, preinstall, and postinstall scripts should not depend on features beyond those of POSIX.2 or POSIX.1. The configure scripts run only on the systems that actually use the software, and hence they need not be as portable as the preinstall and postinstall scripts.

This Standard specifies distributed operations without specifying the mechanism for how it is to be achieved.

Work to specify interoperability for this Software Administration specification has been taken up by The Open Group, which has published a specification defining interoperability using the Distributed Computing Environment (DCE) remote procedure calls (RPC) - see reference XDSA-DCE. Specifications for other technologies to provide distributed XDSA working will be added as and when industry support for them becomes evident.


In defining standards for software administration, the concept of roles is used to specify the way interactions occur in order for software administration to take place. Roles in Software Administration shows the various roles, including those that are outside the scope of this Software Administration specification, as well as those within that scope.

Figure: Roles in Software Administration

Distributed applications require actions to be performed in more than one place (system or directory). These distributed portions have often been referred to as client and server. Software administration tasks also are often initiated by different users at different times. Since the terms client and server have implementation implications beyond the scope of this Software Administration specification, the more neutral concept of role is introduced. This stems from a need to refer to things that occur logically, if not physically, on what might be thought of as a client or server. In the context of this Software Administration specification, roles are simply a convenient way of referring to where function is apparent, with no implication for how this is actually implemented.

It may be helpful to think of roles as separate processes, one per role, but that is only one possible implementation. Roles may operate on separate systems, or hosts, although all roles may operate on the same host. For example, the packager role creates an initial distribution. When copying this distribution, the source role provides read access to the distribution files, while the target role writes the new copy. This new copy may then be read by another source role for another install or copy.

For any implementation, a role consists of the entire set of tasks that may occur within the role. A task is a set of well-defined behaviors and state changes in the managed objects. Tasks are initiated by the system administrator using a specific command in the command line interface (CLI). Tasks are defined by this Software Administration specification in terms of the state changes on the software objects on target hosts.

As each task proceeds, different roles are involved. These roles may be realized on a single machine or could involve a different machine for each role.

Developer Role

Where the software is developed, tested, and maintained.

This role is outside the scope of this Software Administration specification. In Roles in Software Administration , software is developed by the development role in some environment that results in it being in the developed state.

Manager Role

Where each task is initiated and is concerned with taking appropriate action at the completion or failure of a task.

Manager control is understood as a more common need than target control, so at least that should be supported. For this reason, the manager role sets the options for a task, and each of the target hosts implements those options. So, any extension involves a set of ways to define selected control over particular policies. A design for this has not been pursued beyond recognizing the complexity of the problem.

The manager role provides the means of controlling the way software is created, transferred, and installed. In particular it provides an administrative interface to the other roles, enabling their activities to be controlled in a coordinated manner.

Packager Role

Where software that has been developed is organized in a form suitable for distribution.

The packager role transforms a product from the format produced by the developer role to the format specified by this Software Administration specification for use by the next stage of the process, the source, and manager roles. The packager role defines the requirements for this transformation to be successful - the input (the product specification file, and the files it describes), the command line interface to initiate the transformation (.I swpackage ) utility, and the output of the packaging task (packaging layout).

Two distinct, but related, formats for packaged software are supported by this Software Administration specification - a structured format residing within a POSIX.1 hierarchical file system (such as disk, CD, etc.), and a bit stream representation residing on any serial device or file (such as tape, tar archive file, etc.).

Source Role

Where the software exists in a form suitable for distribution and hence forms a context for the establishment of a repository of software from which the manager may choose to distribute to the target.

Software exists in the source until it is removed by a task initiated by the manager.

The source role provides a repository where software may be stored, and provides access for those roles that require the software.

Target Role

The target of a task.

For example, when installing software, the target is where software is installed after having been delivered from a source. As another example, the target for a copy task command refers to the distribution where products are added. For management tasks like removing software, the target refers to either the installed_software objects or the distributions from which software is being removed.

Part of the distributed model involves the target role granting permission to the manager role to perform various software administration tasks. Authority for certain classes of tasks may be individually controllable, for example, modifying vs. listing installed products. While it is entirely conceivable that the target may want to restrict the way authorized tasks are performed, it is beyond the scope of this Software Administration specification.

Client Role

Where the software is actually executed or used, which may be different from where it is actually installed.

Software is configured for use on the client.

An example is installing for an environment where many hosts share software from one system. Diskless systems are one example of systems that do such sharing. A manager role initiates the install task with the source role serving the software from the distribution and the target role installing the software on a fileserver. After the installation is complete, then a client role on each client sharing this software performs configuration for the shared software and the client host.

It is important to understand the difference between the target and client roles. The client role is where the software is actually used and where configuration of the software takes place, while the target role is where the software is installed. Although in many cases these are the same machines, in some cases they are different and the separation of configuration from installation is important. Each target from the targets operand of an install or configure task may identify a target role (if installing but not configuring), a client role (if just configuring), or both (if installing and configuring).

Two examples of when these roles refer to different machines are:

Roles in Software Administration shows a split between the manager role and the other roles. The administrative interface to software administration is provided in the manager role, from which the individual tasks that take place in the other roles are controlled.

This Software Administration specification defines a set of utilities that is such an administrative interface. These utilities provide basic facilities for controlling the individual tasks. Other management applications may be built that provide much more comprehensive software administration facilities. This Software Administration specification defines facilities that enable management applications to control software administration across any number of systems with conforming implementations.

One item of note among the general terms is the definition of symbolic link (see the Glossary). While not yet standardized (see referenced document B21), symbolic links are an entrenched part of existing practice. This Software Administration specification makes no attempt to independently define symbolic links. Rather, the functional characteristics of symbolic links are undefined.


Software administration involves the control of software throughout the software life cycle from the organization or creation of a software object through its installation, maintenance phases, and eventual removal.

The following tasks are identified in this Software Administration specification. The defined utilities provide a way of accomplishing these tasks except as noted.

Install software (swinstall)

This task takes software from a source distribution and installs it on a target file system in a form suitable to be configured on this system or another system sharing this software. Parts of software products (subproducts or filesets) can be installed or reinstalled at different times.

In the case where the system on which the software is installed will also be using the software (that is, it is acting as both a target and client role), configuring the software can be combined with the install software task.

Reinstall software (swinstall)

This task is simply installing the exact same software that was previously already installed.

Configure software (swconfig)

This task takes place on the client role that will be using the installed software. Configuration makes that software ready to use. Configured software can also be reconfigured as required or can be unconfigured (to deactivate a particular version or prepare it for removal).

Update software (swinstall)

This task updates the target file system by installing a newer revision of software than is already installed. This is also referred to as upgrading.

The new revision of software can be installed in the same location as the current revision. In this case, the software configure scripts executed by the configure task need to handle saving or updating the necessary configuration data.

The new revision of software can alternatively be installed in a location different than the current revision. In this case, the old revision may be unconfigured by the unconfigure script executed as part of the unconfigure task, and the new revision is configured by the configure scripts executed as part of the configure task.

Downdate software (swinstall)

This task "downdates" the target file system by installing an older revision of software than is already installed. This is also referred to as "downgrading" or "reverting."

The older revision of software can be installed in the same location as the current revision. In this case, the configuration process of the older version handles the necessary changes in configuration.

The older revision of software can alternatively be installed in a location different from that of the current revision. In this case, the new revision can be unconfigured via the unconfigure task, and the older revision can be configured either independently, or as part of install.

Recover software (swinstall)

This task restores the previous version of software (if it exists) in the case where an update, downdate, or reinstall of software fails. This Software Administration specification defines the minimum required support for automatic recovery process in the install task.

Apply software patch (swinstall)

This task replaces part of a software fileset with a new set of files by installing a fileset with those new files in the same location as the fileset being patched. This is also referred to as fixing software.

Updates and patches can be implemented through standard 1387.2 facilities and control scripts, although these control scripts can become quite complex. This Software Administration specification also proposes significant enhancements to the standard to facilitate these operations.

Remove installed software (swremove)

This task removes software from an installed_software object where it previously was installed. Parts of software products (subproducts or filesets) can be removed at different times.

If the system where the software is installed was also using the software, unconfiguring the software can be combined with the remove software task.

Remove software patch (swremove)

This task removes a patch fileset. This is also referred to as rejecting software.

Filesets related through naming conventions and prerequisites can be used. Restoring patch files when removing the patched can be achieved via remove control scripts.

Verify the installed software (swverify)

This task checks that software previously installed still exists and is intact. If operating on a system that was configured to use the software, it can also check that the software is configured properly.

List installed software information (swlist)

This task provides a list of the software that has been installed on a target. Options are available to specify which software packages are to be listed and to control the amount of information provided.

Fix installed software information (swmodify, swverify)

This task modifies information about software that has been installed on a target. Options are available to specify which software packages, and what information about those packages, are modified.

Package software (swpackage)

This task takes place in the packager role and transforms developed software into the software packaging layout suitable for distribution. The metadata that defines the software objects to be packaged is contained in the product specification file (PSF).

Copy distribution software (swcopy)

This task copies distribution software between a source and a target, for subsequent use of that target as a source. Copying software can be used to merge distributions, to distribute products to the installation targets, and then install from that local copy, or to copy part of a distribution to a removable media for physical distribution (as opposed to electronic distribution).

Remove distribution software (swremove)

This task removes products from a target distribution.

Check/verify distribution software (swverify)

This task checks that a target distribution exists and is intact.

List distribution information (swlist)

This task lists source or target distribution information. Options are available to specify which objects in a distribution are to be listed, and to control the amount of information provided.

Fix distribution information (swmodify, swverify)

This task modifies information that describes, and is contained within, target distributions. Options are available to specify which objects in a distribution are modified.

License installed software (undefined)

How software licenses are managed is undefined within this Software Administration specification.

The task definitions were based on study of existing practice for software administration. This included presentations on existing practice by many different system vendors and system administrators. From these, a functionally adequate base was selected upon which all parties could build. While it was recognized that this did not address every concern, it was felt that that the utility descriptions (including detailed behavior), software structure definitions, and media layout, provided an excellent starting point. After comparing various existing practices, these choices appeared to be quite similar to other existing practices in many details of these key areas.

Update Requirements

This XDSA specification enhances the IEEE 1387.2 Standard in its provision for handling updates.

Customer update requirements for software updates were perceived as follows:

Provider update requirements for software updates were perceived as follows:

Patch Requirements

This XDSA specification enhances the IEEE 1387.2 Standard in its provision for handling patches.

Customer patch requirements were perceived as follows:

Patch provider and support organization requirements were:


The intended conformance classes defined in this Software Administration specification are derived somewhat from the examples of POSIX.1 and POSIX.2, with variations to support unique situations.

Implementation conformance is intended to be based on implementation of the utilities defined in this Software Administration specification, and on the proper POSIX.1 and POSIX.2 support from the operating system.

There is scope for a new conformance class - Distribution Conformance - to allow suppliers of software to package their software in a conformant manner. Distributions have many of the characteristics of applications using POSIX.2, since the distributions contain executables (presumably shell scripts).

Implementation Conformance
This class of conformance would require support of all the POSIX.1 and POSIX.2 functionality referenced in this Software Administration specification. The requirements from POSIX.1 are primarily for hierarchical file system support, including the file attributes of owner, group, and mode. In addition, the POSIX.2 utilities are required to support portable scripts.

This would assure that every Conforming Implementation would be able to install any strictly conforming distribution properly, including the proper settings of file attributes. One might question this need if one is installing software particular to a system that is not POSIX.1 conformant. It is the pervasive ability to serve the software over a distributed file system that makes critical the need for all conforming implementations to understand at least one set of well specified operating system behavior. The one set of operating system behavior chosen is POSIX.1. The need for POSIX.2 is primarily driven by the presence of executable control files within distributions. At least one guaranteed mechanism is required to invoke those files, and the shell interpreter was chosen for that purpose. Further, developers of portable scripts need a guarantee of some basic set of utilities with which to work, and the POSIX.2 utilities were chosen for that purpose.

A conforming implementation need not include the POSIX.1 and POSIX.2 implementation itself, but it must document how such can be obtained for the systems that the implementation supports. It is reasonable to assume that a given implementation, conformant in the presence of proper POSIX.1 and POSIX.2 support from the operating system, may still operate correctly on some distributions even when the proper operating system support is not present in full or in part.

Distribution Conformance
Strictly Conforming POSIX.2 Distribution
The Strictly Conforming Distribution class is intended to provide the highest degree of portability for a distribution. Conformance to such a class would guarantee that any conforming implementation could install this software properly.
Conforming POSIX.2 Distribution
The Conforming Distribution class is intended to guarantee that any conforming implementation can copy or install this software properly. This class would also allow for additional functionality, which may come either from implementations that can take advantage of additional attributes, or from software being able to store and retrieve that information from any Conforming Implementation.
Conforming POSIX.2 Distribution Using Extensions
This class is intended to allow evolution of this Standard, but in an open, consistent and well-documented manner. Examples of this are compressed media or bootable serial media. Both of these are features were recognized by the developers of this Standard as important, but consensus to include them in the 1387.2 Standard was not achieved.

This class would also provide flexibility for distributions needing to conform to other constraints related to the support of POSIX.1 and POSIX.2. There was strong support among the user community in the 1387.2 development project for support for interpreters other than sh. Support for other interpreters also permits the use of such distributions on systems, such as DOS, which are not conformant with POSIX.1 or POSIX.2.

Software Structures

Classes and Attributes

An example of the structure of the software objects for this Software Administration specification is illustrated in Example of Software Structure .

Figure: Example of Software Structure

At the top of the hierarchy is a host, which is a system that conforms to this Software Administration specification. It is the starting point for finding all the software on that system that falls within this Software Administration specification. A host contains software_collections.

There are two distinct types of software_collections, as listed in the following, that may exist within a conformant system:


A distribution consists of software products, in a form ready for installation. A distribution may also contain software bundles. There may be many distributions within a host.


An installed_software object consists of products installed from a distribution. An installed_software object may also contain software bundles. There may be other installed_software objects for use by this system or for other systems.

Software is organized into a hierarchy of objects, as described in the following, that are operated on by the utilities defined in this Software Administration specification:


A product consists of filesets and control scripts, plus all the associated metadata. The content of a product may be specified as a collection of subproducts, filesets, or a combination of the two.


A bundle is a grouping of other software objects and is a convenient way to reference a set of software.


A fileset consists of the actual files plus control scripts. Filesets are generally the lowest level of software object that can be operated on by the utilities.


Subproducts are a grouping of other subproducts, or of filesets, or of some combination, that resolve to a group of filesets. Subproducts are a convenient way to aggregate filesets.

The software_files define the files and control_files that are contained in the software objects that are operated on during a software administration utility. There are two classes of software_files as described in the following:


Control_files consist of control scripts and other files that are used in various ways by the utilities. Control scripts are executed by the utilities at various points in a task. Control scripts provide a way to perform steps, in addition to those executed by the utilities, at various points in the task such as preinstall checking, postinstall customization, configuration, and verification. Either a single script with multiple entry points, or multiple scripts can be defined.

Most control scripts are run on the target, which may be a different architecture than the client on which the software operates. They should, therefore, use POSIX.2 utilities, except where they can determine that they are running on the client.

In addition to scripts, other control_files provide input to the control scripts, or to the utilities directly (for example, the response and space control_files).


Files are the lowest level of object defined by this Software Administration specification. Files contain the attributes describing the file including the contents of the file and its installed location.

The distributions and installed_software objects are the sources or targets of a software administration command. The software objects (products, filesets, bundles, and subproducts) are the objects that are being applied to those targets.

This Software Administration specification describes the structure and the attributes for software_collections, software objects, and software_files. It also describes the behaviors for the utilities that operate on these objects. However, these structure definitions are not managed object classes in the ISO sense because the behaviors are not described in terms of methods within object classes1.

Software Object Containment shows the components of the software object hierarchy. The containment arrows designate objects that are defined within the context of their containing objects. An object can only exist within one containing object. The identifier of an object (for example, the tag attribute of a fileset) only needs to be unique within the scope of the containing object.

The reference arrows designate objects that are included when this object is operated on. An object may be referred to by more than one object. Bundles need not refer to entire products, but can refer to individual filesets or subproducts. Fileset and subproduct objects can be referenced directly by bundles by also identifying the product of which the fileset or subproduct is a part.

Figure: Software Object Containment

Software Object Inheritance shows the software administration common classes and the software objects that inherit attributes from these common classes.

Figure: Software Object Inheritance

Interoperability between implementations of this Software Administration specification may be achieved through the definition of methods for the first two of these common classes, "software_collections" and software. The software_collections are the source and target objects for software administration, while the software objects are the objects that are operated on within the context of the software_collections. Operations on individual software_files independent of operations on software objects is undefined.

This Software Administration specification also does not define how remote file systems are managed. In the simplest case, each file system is "local" to a single host, and all installations may be directed to the file system through an agent process on that host. Thus, files on a file system are contained within one of the installed software collections contained below that host. On the other hand, an implementation may also choose to allow installation to a remote file system over a remote file system protocol. That is, the target process is running on a host that is different from the one that contains the file system. In this case, the files on that file system may be contained within the same software collection as before, or may be contained within a local software collection. In another implementation, all software collections may be stored within a global naming service instead of below any particular host.

An implementation may choose to define a software host object, or manage software as part of a more general host object. The attributes of a host object that are of interest to this Software Administration specification are shown in Possible Attributes of a Host Class .

Table: Possible Attributes of a Host Class

Attribute Length Permitted Values Default Value
host Undefined Portable character set None
os_name 32 Portable character set None
os_release 32 Portable character set None
os_version 32 Portable character set None
machine_type 32 Portable character set None
distributions Undefined List of distribution directories Empty list
installed_software Undefined List of installed_software directories and catalog identifiers Empty list

The following are the attributes of the hosts that contain software_collections managed by this Software Administration specification:


The list of distribution.path attributes for distributions in the software host object.

These describe the PATHNAME portion of a software_collection source or target.


Identifier used to specify the host portion of a software source or target.

Identification of a remote host system is dependent on the networking services implementation and thus the syntax and semantics of the host name is undefined within this Software Administration specification.


The list of installed_softwarepath and installed_softwarecatalog attributes for installed_software objects in the software host object.

These describe the PATHNAME portion of a software_collection target.


Corresponds to the machine member of the uname() structure defined in POSIX.1 section 4.4.1.

It is the hardware type on which the system is running.


Corresponds to the sysname member of the uname() structure defined in POSIX.1 section 4.4.1.

It is the name of this implementation of the operating system.


Corresponds to the release member of the uname() structure defined in POSIX.1 section 4.4.1.

It is the release level of the operating system implementation.


Corresponds to the version member of the uname() structure defined in POSIX.1 section 4.4.1.

It is the version level of this release of the operating system.


This class definition exists for convenience in defining the classes that inherit from it. It is not intended that any direct instances of this class be created, but only of the classes that inherit from it.

Multiple versions of products and bundles are possible when subsequent releases of a product or bundle have different revision numbers, and when products or bundles targeted for different machine types or other OS attributes define the architecture attribute differently.

The layout_version attribute is the version number of this Software Administration specification to which the distribution conforms. The name of this Software Administration specification (for example, P1387.2-19xx) was considered but there was concern that the delay between IEEE acceptance and ISO acceptance would make it hard to pick the year correctly. It is not clear when to change the number from 1.0 to 1.1 or even from 1.x to 2.0.

It is possible for an INDEX file describing a distribution to contain products with different values of layout_version. The software_collection layout_version refers only to the format of the distribution attributes and the product keyword. After the product keyword, the product layout_version defines the format of the definitions of all objects within that product.


POSIX.1 allows for different pathname and filename sizes. Thus it is possible for a distribution to be created on one system and not be readable or installed on another system (each of which conforms with this Software Administration specification) because of differences in their POSIX.1 {NAME_MAX} and {PATH_MAX}. Consideration was given to attributes defining the longest sizes of file names and paths on a distribution, but these were not included since their use could neither ensure failure nor success of installing or copying a particular product from the distribution. Another issue implementors should consider is the maximum name and path that may be contained within a supported archive.

The need for the media_sequence_number attribute is to number the tapes (or disks or whatever) if a distribution is on more than one of them. If there is only one, then its number is 1.

The following attributes at one point were listed as distribution attributes. However, it was determined that the only time it could be guaranteed that these attributes were accurate was for an initial distribution definition. As soon as a swcopy or swremove operation occurred on a distribution, the attributes could be invalid because it would be impossible to modify these attributes in any logical manner based on the operation. It is recognized that these attributes are valuable and many vendors may choose to put them in as vendor extensions.


A short name associated with the distribution, used for selecting the distribution from the command line


A longer name used for display purposes.


A more detailed description of the contents of the distribution.


A revision associated with the distribution.


Describes the type of media being used (for example, CD-ROM, 8 mm, etc.)


The copyright notice for the distribution.


The date, in seconds since the Epoch, when the distribution was made.


The vendor part number for the distribution.


A sequence of characters used by a vendor to describe the machine or product. This is presumably more "user friendly" than the values returned by the uname utility.

Usually distributions will be created upon creation of the first product with swpackage or swcopy. Usually distributions will be removed as a part of removing the last product with swremove. An implementation may choose to provide more explicit control for creation and deletion of empty distributions. The swcopy and swremove utilities should be used for this purpose. The swmodify utility may also be used.


This section is inserted to maintain parallel numbering with the main section numbering in Software Structures . No additional rationale is required under this heading.


The installed_software catalog may be located by something as simple as a pathname where the catalog is stored as a file, or it could be located in a more complicated fashion such as with a key from a directory service used to identify all or part of a database.


The vendor.tag attribute is intended to distinguish software objects from different vendors that happen to have the same product.tag. A vendor should attempt to choose a vendor.tag that is unique among all vendors.


This section is inserted to maintain parallel numbering with the main section numbering in Software Structures . No additional rationale is required under this heading.


This class definition exists for convenience in defining the classes that inherit from it. It is not intended that any direct instances of this class be created, but only of the classes that inherit from it.

This standard has defined four related software objects:

See Software Object Inheritance . Implementations are encouraged to present these to the user as hierarchy of similar "software" objects, and to actually implement these so that they differ only as needed. That is to say, an implementation should use inheritance from a common class as much as possible. The rationale for the four differently named software objects is as follows:

The need to localize the following descriptive software and vendor attributes was recognized - title, description and copyright. However, since the existing practice for localization of software information files in portable media is immature, this has been deferred to a possible future revision of this Software Administration specification.

Until a future revision of this Software Administration specification addresses localization, one recommended way to internationalize these attributes is to create vendor-defined attributes with the format:


where keyword is "description.", "title", or "copyright", and <LANG> is the value of the LANG environment variable. An implementation should then recognize if LANG is set to a value other than its default and search for a corresponding attribute. If that attribute does not exist, then the default one will be used. For example:

product tag GreatProduct title "This is great!" title.FRENCH "C'est magnifique!" title.GERMAN "Sehr gut!" description"Long boring paragraph why this is great" description.FRENCH "... description.GERMAN "... . . .

Note that the tag, revision, and other attributes that affect the defined behavior of the implementation, shall not be internationalized. For this revision of this Software Administration specification, this includes all defined attributes except title, description, and copyright.

The size for the software may be larger than that supported by the POSIX.1 size_t structure since software can contain many files. It is recommended that an implementation allocate at least 64 b for the internal storage of the software size attribute.


The value of the revision attribute is interpreted as a . (period) separated string, as defined in Limited Conformance , and further in Software Specification and Logic . This definition permits the use of such a string, but does not require it. The string can be constructed entirely without the use of periods. An example of the comparison is:
A1.003.01 < A.004.00 < B.000.00 A1_003_01 < A_004_00 < B_000_00 First < Second < Third First < Fourth < Second

Historically, some implementations computed the value of instance_id sequentially, while other implementations have used an algorithm based on the product tag, vendor_tag, and the various machine type attributes. No implementation is specified, other than to guarantee that the tag and instance_id uniquely identify the product within the distribution or installed_software object. This is to make it easier to specify a particular product when there are other products sharing the same tag as would be the case when there are different product instances in a distribution for several machine types or multiple concurrent versions on a host.

The vendor_tag attribute is intended to be universally unique to distinguish product and bundle software objects that otherwise would be treated as the same object if the tag, revision, and architecture attributes were the same. Guaranteeing universal uniqueness is difficult at best, and no need was seen at present to cause the value of vendor_tag to be either some sort of machine-generated universally unique value or officially registered.

Multiple versions of the "same" product or bundle (ones with the same value for the tag attribute) is supported by each version possessing values of the version distinguishing attributes unique within that installed software catalog.

The architecture attribute should include information related to four uname() structure members. The architecture attribute is needed for software_specs since the patterns used for determining compatibility in the attributes related to uname() can be somewhat complex and contain patterns, while software_specs themselves can contain patterns.

It is recommended that a set of guidelines be used for the architecture attributes to maintain a consistent "syntax" for related architectures. This increases the usability of this field for users selecting software. An example guideline is to order any information contained in the value of the attribute in a consistent way, separated by a consistent delimiter. For example:

architecture sunos_4.1_sun4
for a product with the attributes:
os_name sunos os_rev 4.1.* os_ver * machine_type sun4*
Another example is:
architecture hp-ux_9_pa-risc
for a product with the attributes:
os_name hp-ux os_rev 9.*|10.* os_ver [a..e] machine_type 9000/[6..8]???

Product machine attributes describe the target systems on which this product may be installed. Each of these keywords are related to a POSIX.1 uname() member and may be defined as a simple string, or a software pattern matching notation. How compatible software is determined depends on whether the products are being installed on the system that will be using them, or whether the installation will be used by other systems with perhaps different attributes.

If a uname attribute is undefined, the behavior is essentially the same as if it were defined to be * (meaning compatible with all systems).

The product directory for an application should be the directory that is part of all paths in the product. Thus, if an application has three filesets that contain files below /appl/console , /appl/agent , and /appl/data respectively, the attribute should be set to /appl . If a user relocates the product with a command like:

swinstall appl,r=1.0,l=/disk2/appl
then all three filesets have the same location attribute. If the user relocates the product to three different locations:
swinstall appl.console,r=1.0,l=/disk1/appl swinstall appl.agent,r=1.0,l=/disk2/appl swinstall,r=1.0,l=/disk3/appl
then each fileset will have a different location attribute. There will be three product instances containing the three filesets (since products versions are distinguished by location), but the user can still identify all three filesets as one with the specification:
swverify appl,r=1.0,l=*

Alternatively, the user could relate all these locations with the same version qualifier, such as "q=current" as follows:

swinstall appl.console,r=1.0,l=/disk1/appl,q=current swinstall appl.agent,r=1.0,l=/disk2/appl,q=current swinstall,r=1.0,l=/disk3/appl,q=current
and subsequently identify all pieces with:
swverify appl,q=current

The postkernel attribute supports the ability to install one operating system in proxy (to an alternate root) by another implementation that does not understand that operating system. All products that contain kernel filesets that will be installed into the same installed_software object should have the same path defined. There should be one core OS kernel fileset that includes this path in its set of files so that it has been installed by the time the postkernel script is executed.

In general, a product with no preinstall or postinstall scripts is recoverable. However, if there are preinstall or postinstall scripts, then unpreinstall and unpostinstall scripts shall be provided if any steps need to be undone to support autorecovery.

There was an issue whether dependencies should be an attribute of a product. The following types of dependencies have been discussed:

The last three dependency types are not necessary if the first three types exist (which they do), since those dependencies can be specified in terms of the others. For example, if an entire product depends on a second product, then the second product can be defined as a dependency for all filesets in the first product.

The developers of this Software Administration specification recognized that numerous additional dependency requirements are possible, particularly for software updates. These may be handled via checkinstall scripts, and can be considered for future revisions of this Software Administration specification.

The intention behind the inclusion of the layout_version attribute within a product is that it be required if its value is different than that for its associated software_collection .


Bundles serve two purposes - they allow the software supplier to group different subsets of products into new configurations or products, and they allow the software administrator to build useful groups of software (configurations) from already defined bundles and products.

The bundle class does not have location or directory attributes. This is because software_specs within the bundles can refer to products with different default directory attributes or even products that have been relocated.

Bundles have "uname" attributes that only have any value if the bundle aggregate has a different compatibility than that of any of its contents. Besides offering more control to the person defining the bundle, it is useful in a GUI that wants to only display compatible software by default. For example, a bundle may contain one product that operates on a system with an uname attribute of "A" and another product that operates on systems with uname attributes of "A" or "B". In this case, it might be useful to define the bundle attribute to be "A". Since it is possible that not all the bundles contents exist in a particular distribution or installed_software object, it may not be possible to determine the compatibility of the bundle in all cases unless the bundle attributes are also defined.

The vendor_tag attribute is intended to be universally unique to prevent naming clashes for similarly named products and bundles from different vendors. Guaranteeing universal uniqueness is difficult at best; it was deemed unnecessary at present to cause the value of vendor_tag to be either some sort of machine-generated universally unique value or officially registered.

The intention behind the inclusion of the layout_version attribute within a bundle is that it be required if its value is different than that for its associated software_collection .

The value of the bundlecontents attribute is not modified when a location is specified for a bundle, allowing future resolutions of its contents to remain consistent. For example, assume bundles "CAT" and "DOG", and products "FOO" and "BAR", all with directory attributes defined as "/":

bundle tag CAT contents DOG,l=/dog BAR,l=/bar bundle tag DOG contents FOO,l=/foo

When the bundle "CAT" is installed and relocated to /cat, the following objects are installed:

CAT,l=/cat DOG,l=/cat/dog FOO,l=/cat/dog/foo BAR,l=/cat/bar

So, when resolving "CAT,l=/cat" in installed software, applying the proper locations to the software_specs in the contents will result in the same software_specs in the installed software.

Bundle definitions are only copied or installed when explicitly specified since they are external to the product and not always applicable to the use of the product installed. The creator of a product has no control over what bundles reference it. For example, a product may be a member of numerous bundles, and many of those bundles will likely have nothing to do with the bundles and products chosen to be installed. Also, see Subproducts .

Bundles and subproducts have lists defining their contents that are always copied (.I contents is a static attribute). So, if a partial bundle or product is copied, the value of the contents attribute does not change. However, by comparing that attribute to what objects are actually installed, "completeness" of a bundle or subproduct can be determined.


The media_sequence_number is used for serial distributions to describe which media the archive containing the fileset starts on. There is generally one archive per media, unless a fileset is larger than a media. Each media has a unique sequence number whether it begins an archive or continues a previous one.

At one point a fileset class attribute existed that could contain the value of recommended, mandatory, or optional. The attribute was removed because it was felt that this Software Administration specification could not specify any behavior for the attribute. It would be possible to make a specific fileset mandatory by having all other filesets in that product specify it as either a prerequisite or corequisite.

Another way to handle recommended, mandatory, or optional filesets would be to create subproducts with tags of the appropriate names. Although this Software Administration specification does not specify any behavior based on the name of subproduct tag, a specific implementation could define behavior as an extension.

When there is a dependency on a software item that is the ancestor of a new software item, it is desirable for the standard to allow that new software item to meet that dependency. This is more complex than might initially be apparent, since dependencies and ancestor definitions involve ranges of revisions and other expressions. The working group felt a separate "supersedes" attribute might be a better solution, so explicit supersede control is separate from the ancestor/match_target functionality. Requiring supersedes to be fully qualified software specs only would help eliminate the "pattern-to-pattern" comparisons.

Patches do not have to supersede other patches in the same fileset. This allows "point" patching: separate patches that patch separate parts of the same fileset.

Patches that supersede all previous patches (cumulative patches) can be specified with a single software_spec if a patch strategy uses the same product and fileset tags, and an ascending revision numbering scheme.

supersedes product.fileset,r<revision


Unlike bundles, subproduct definitions (that are internal to a product) are copied or installed when any fileset specified in the contents attribute of the subproduct is copied or installed. Products are meant to be sets of related software and are usually created and managed by one person or organization. Additionally, subproducts are normally used to specify useful subsets of filesets within the product, which in turn are useful for dependencies. With subproducts, the "parts make up the whole."


This class definition exists for convenience in defining the classes that inherit from it. It is not intended that any direct instances of this class be created, but only of the classes that inherit from it.

The compression_type attribute allows compressing and uncompressing of individual files during swcopy, and uncompressing during swinstall. The way in which an implementation uses this attribute is undefined, although the general thought was that this would normally be the name of a compression/uncompression routine with a simple interface.

An implementation should be flexible in locating routines specified by compression_type, utilizing any or all of the following:

No particular compression method is specified in the standard largely because the developers of this Software Administration specification saw no standard for file compression and did not want to specify all of the details of the compression methodology as part of this Software Administration specification. It was generally agreed that to achieve adequate interoperability, a single method of consensus should be supported by all implementations. It is likely that the format used by the gzip utility is appropriate for all implementations. Each implementation may support any number of other methods.

The interface to the compression routine was also left unspecified. It is recommended that input be taken from stdin and output be directed to stdout, that the routine operate with no option to imply compress, and that a -u option imply uncompress. However, specific compression routines may require more complex interfaces.

The group also considered archiving of compressed files, that is, concatenation or other combination into a single file. The main purpose of this would be to save cluster space on diskette distributions. It was finally decided that the risks for current standardization were too high - especially if an archive extended over more than one diskette - and the issue was left implementation dependent. In implementing this, there should be consideration of the following factors:

Finally, compression support for swpackage was considered, and deemed as unnecessary, since compression can be achieved by copying after packaging. But an implementation can easily add attributes to achieve this function.


The letters chosen for the file type attribute are consistent with the syntax of the find utility with the -type option, as defined in POSIX.2. Hard links are not specifically mentioned in POSIX.1 section Symbolic links are not mentioned in POSIX.1 but are included to support existing practice. Work to standardize symbolic links is included in referenced document [B21]".

Implementations running on operating systems that do not support a POSIX.1 file system can interpret the defined attributes in any appropriate way. Any implementation can extend file attributes with additional attributes appropriate to the file system in question. To avoid confusion when defining new attributes for a particular file system, it might be best to prefix such attributes with a designator of the file system. An example, for a FAT file system, might be the attributes FAT_Hidden and FAT_Readonly.

There was some debate whether the major and minor attributes are appropriate or not since there is no standard that specifies how these files are created. In addition, this Software Administration specification specifies that the serial distribution be in POSIX.1 cpio or tar format; however these attributes are biased towards tar format as opposed to cpio format.

Considered was a size file type (z ) that was removed in favor of the space control_file similar to SVR4. An implementation may choose to internally implement a size type or a separate size_file object to represent the data from this file.

The developers of this Software Administration specification considered an is_exclusive (directory) attribute that was removed due to objections that the utilities would remove files that they did not have recorded in their database. Also, this was not a common need, and can be implemented either as vendor extension or by having software fix script implement similar functionality.

There has been much discussion about compression being handled within the scope of this Software Administration specification. Currently there are ways that both implementations and individual software products can handle compression. Compression can be handled through cooperation of the source and target roles, if they are from the same implementation. Software vendors can choose to ship their files compressed and uncompress them as part of the postinstall script. They can add a space control_file to account for the extra space required.

A similar need would apply to other post processing, such as for ANDF files that are processed as part of postinstall or configuration.

Though it may be adequate for protecting against accidental damage, the existing POSIX.2 cksum is considered inadequate for virus protection. Implementations may wish to create additional vendor-defined attributes and utility behaviors for this purpose.

Each of the prerequisite or corequisite dependency_specs in the list is required to resolve successfully in order for dependencies to be met. Also, a dependency_spec can contain alternate software_specs separated by the | (vertical line) character (see Software Specification and Logic ). So, if a fileset has a corequisite dependency on software, expressed with a Boolean equation (A|B|C)&(D|E) , this can be specified in a PSF as:

corequisite A|B|C corequisite D|E

There are files (particularly for OS software such as /etc/rc for SVR4 and autoexec.bat for DOS) that are modified between software update times. These may be termed modifiable files. Although OS modifiable files are slowly being replaced by mechanisms where applications can simply add their own requirements as separate read-only files in a particular directory, there currently would be some value in supporting features where modifiable files are compared with the original files to see what changes need to be applied during software updates. Actually implementing these changes is a more difficult problem since it requires knowledge of the formats of the files being updated. Similarly, reversing (during swremove) changes made to modifiable files (during swinstall and swconfig) is an exceedingly difficult problem. The existing practice for treating modifiable files is fairly ad-hoc. It was not feasible to address all of the possible needs for updating modifiable files. Instead, it does provide the attribute is_volatile for files that may be modified after installation, and leaves the rest of the treatment of modifiable files as either implementation defined, or handled in control scripts. This area may be considered for a future revision of this Software Administration specification.

Control Files

Using tags as the identifier of when a script should be executed (independent of the path the script is stored as) allows anywhere from one file per tag to one file for all tags. A concern on PC or DOS systems is that requiring more than one control script for all tags is a space problem. Instead, software vendors might prefer a single master script that took care of all needs. Multiple scripts are also supported, since many software vendors favor this approach over a "mega-script." However, other vendors may prefer the single script approach, especially to save space if there are many scripts defined for this product that share a lot of the same code.

Control files do not have mode, owner, group, uid, gid, and mtime attributes since they are not necessary for the execution of the control scripts or for the management of these files within the distribution or installed software catalog. However, an implementation shall ensure that they are executable.

The interpreter attribute has two uses. It is useful for those who choose not to use the POSIX.2 shell, that is, sh. It is also useful for systems that would not otherwise require POSIX.2. Those creating distributions and control files are encouraged to use the POSIX.2 shell for portability.

Common Definitions for Software Administration Utilities


No additional rationale is required under this heading.


No additional rationale is required under this heading.


The -d option is needed to remove ambiguity for utilities that operate on both distributions and installed software.

The -r option is needed for the following reasons. Installing software at / involves a somewhat different set of operations than software installed at an alternate root, as well as a different implied use. Software installed on alternate roots is not configured in the context of the target where the software is installed, but rather in the context of the client actually running the software. Another difference is that the target is not rebooted after installing software that requires a reboot (the clients of the software need to be rebooted). An alternate root containing operating system software can be thought of as a root to which one could chroot(). From a usability standpoint, it is important that alternate roots are understood to be different than relocating a software product, or specifying an alternate catalog for the same root.

Related to the -s option, an implementation could define an additional source syntax to use well-known sources whose existence is available through some sort of directory service.

The -s option could be extended to supported multiple source specifications. There are several possible ways to interpret multiple sources, including searching sources sequentially, ignoring all specifications after the first one, using the last specification, or choosing the "best" source based on criteria such as performance or ability to reduce network load. It may even be desirable for multiple source specifications to be interpreted differently for different commands.

An implementation may implement the -p option (preview) by simply executing the command through the analysis phase. Alternatively, an implementation may emulate the execution phase, listing the operations that would occur, including listing control scripts that would be run, but not actually performing those operations. As preview is undefined, other alternatives are possible.

Non-Interactive Operation
It is recognized that there may need to be some sort of interaction with the user in order to handle multiple volumes (for example,for example, tapes) for sources and targets.


The 1387.2 developers concluded that the @ character does not have any applicable precedence as a separator of operands, so the use of @ in mail addresses and BSD commands is a bit different. Another point was that having two lists of operands was not desirable in any case.

On the other hand, the two types of operands are the two key objects upon which the utilities operate. The syntax is valid according to the utility guidelines from POSIX.2 section 2.10 2. Distributed utilities extend the problem space that POSIX.2 has already addressed, thus the need for precedence might be less. Thus, it was decided that the @ was acceptable, and perhaps desirable over the alternatives.

One alternative was to move one or both operands to options (such as -S for software and -T for targets). But, it was felt that this was not necessary because there are already -f and -t options for files containing lists of operands. Another point was that listing target operands on the command line was not critical in any case, as an administrator of many systems would not use either the @ targets or -T target syntax.

Software Specification and Logic
Using a less formal grammar convention that defines zero or one item by enclosing these items in [] (brackets) and zero or more repeated items in {} (braces), the following shows a common subset of the software_spec syntax:
software_spec : bundle_tags [ product_tags ] [ version ] | product_tags [ version ] | '*' [ version ] ; bundle_tags : bundle { '.' bundle } ; product_tags : product [ '.' subproduct { '.' subproduct } ] [ '.' fileset ] ; version : { ',r' rel_op revision } [ ',a=' architecture ] [ ',v=' vendor_tag ] [ ',l=' location ] [ ',q=' qualifier ] | ',*' ; rel_op : '==' | '!=' | '>=' | '<=' | '<' | '>' ;

The keywords bundle, product, subproduct, and fileset refer to the tag attributes of those objects. The value of revision is usually a dot separated string compared to the value of the revision attribute of the first object. The values of architecture, vendor_tag, location, and qualifier are usually exact strings or patterns compared to the like-named attributes of the first object. These version attributes can validly be specified like revision is, but operators and multiple specifications do not make much sense.

Examples of software_specs are:

* Networks Networks.X11 Networks.X11.Runtime,a=*80?86* X11 X11.Runtime X11.Runtime,r=4,v=CloneInc X11.Runtime,r>=4.0,r<5.0 X11,r=4.03.07,l=/usr/X11R4 X11,r=5.00,l=/usr/X11R5,q=latest X11,* *,a=*80?86*

A software_spec shall begin with a bundle or product tag. A particular bundle or product object can be determined since they share the same name space (they also have different instance_id attributes).

The location attribute applied to the product means all filesets in that product in that location. This is the same set of filesets as if the location attribute was applied to the filesets.

Since the components of the version_qualifier of a bundle_software_spec refer to the attributes of bundle objects, there is no way to select one version of a product if more than one version is specified in the bundlecontents. Neither the inclusion of multiple versions of a product within a bundle, nor the specifying of partial bundles, is seen as the normal use model, so having this Software Administration specification limit the flexibility slightly in this area was deemed as acceptable.

This Software Administration specification permits the use of values other than those defined in Software Specification and Logic for ver_id. This Software Administration specification also permits the use of ver_id in conjunction with attributes and objects other than the first listed in a software_spec. This allows additional flexibility for identifying software objects.

A possible syntax for these vendor extensions include, but are not limited to:

ver_id attribute object
br revision bundle
ba architecture bundle
bv vendor_tag bundle
bl location bundle
pr revision product
pa architecture product
pv vendor_tag product
pl location product
fr revision fileset
fl location fileset

The ver_id fr is seen as most useful since it can identify a particular fileset object within a product where the product may not have a revision, but the fileset does. Note however, that any object can still be identified with only the attributes defined in this Software Administration specification. For example, if a bundle includes two partial products with the same tag value but different revisions or locations, these partial products could be identified with the standard syntax by excluding the bundle portion of the software_spec. For example, bundle.product,pr=1.3 could also be identified by a software_spec of product,r=1.3.

In another example, the fileset that could be identified by its revision (product.fileset,fr=1.3) could also be identified by a software_spec (for example, product,r=revision), where revision refers to the product revision, including possibly the empty string.

Relocation occurs by replacing the part of each file path as it occurs in the distribution, with the location specified and using the resulting path for installation. This is still relative to the installed_software directory described below. See swinstall for more information.

Using a sw_pattern in a software_spec is a way for the user to indicate that all software objects that match the software_spec are to be included. For example, applying the software_spec "*" to swcopy means to copy all software in the distribution. Applying the software_spec "Foo,*" to swremove means to remove all versions of Foo.

The behavior for swlist is different (by default including all software if none is specified) because this is the command that is used to find all versions of software, and because listing cannot negatively affect the state of the software_collection.

If using software pattern matching notation characters on the command line, they shall be escaped or enclosed in single quotes to avoid matching files in the current working directory.

This specification provides the means to select products and specify dependencies using a single syntax. The use of the shell-type pattern match specified in POSIX.2 section 3.13 allows for reasonable specification of sets of values that share such patterns. Thus, for example, a specification of "a=HP-UX*" may be used to select packages for any of a set of architectures. The specification using the relational operators provides support for testing the type of release/version specifications that are frequently used by vendors. In particular, it provides support for testing when a numeric test is needed (for example, comparing 2.9 to 2.10 as version levels of a product). Additional operators such as >> were considered. The specification of the >> operator allows the user to specify the selection of the most recent (highest version number) of a set of otherwise identical packages. This exposes to the interface the mechanism used by swinstall to select such a package.

The range of attributes that may be specified allows for selection of packages that may be needed to support code serving to alternate architectures, or other operating environments. In addition, it provides the needed support to specify installed software that may only be distinguished by the location of installation.

Examples of fully-qualified software_specs are:

Foo,r=3.0,a=,v=XT BundleA.Foo,r=1.0,a=,v=XT Dow.Bar,r=2.0,a=SunOS,v=,l=/opt/foo.2

It is possible for bundles to contain software_specs that are not fully-qualified. This is not recommended for bundle definitions provided by software vendors because the results of operations on this bundle may be undesirable for an administrator. However, there is some flexibility provided by ambiguous software specs that administrators may want to use.

For example, a bundle with contents "*.Man" could be used to manipulate all "Man" filesets or subproducts in all products.

If a vendor includes any wildcards in a software_spec in a bundle definition, then the vendor_tag attribute should be included and its value should have no wildcards, thus limiting the scope of the pattern matching.

The difference between "FOO,v=" and "FOO" is that the first will only match a product or bundle "FOO" where vendor is not defined, while the second will match a product or bundle "FOO" with any vendor definition.

Source and Target Specification and Logic
Using a less formal grammar convention that defines zero or one item by enclosing these items in [] (brackets) and zero or more repeated items in {} (braces), the following shows a common subset of the software_collection_spec syntax:
software_collection_spec : [ host ] [ ':' ] [ path ]

Examples of distribution software_collection_specs are:

/var/spool/sw hostA hostA:/var/spool/sw

Examples of installed_software software_collection_specs are:

/ hostA hostA:/

Target distributions in the serial format need not be supported for swverify, swremove, and swmodify as this requires the implementation to unload the entire distribution, merge in the changes, then reload it. The user can accomplish this (and an implementation can implement this) by first copying the distribution into a directory format, implementing the changes, then copying the distribution back to the serial media. This operation also could require significant temporary disk space.

A similar rationale applies to swcopy, and swpackage, which by default, overwrite the existing distribution instead of merging in the specified software.

External Influences

Defaults and Options Files
For SVR4 or similar file system layout, the defaults file may be located in /var/adm/sw/defaults. The use of this location is strongly encouraged.

The 1387.2 developers considered the difference between "system-level" defaults and "site-level" defaults.

The former is provided by the implementation of the utilities and the latter is constructed by the administrator. The intent here is for the implementation to respect any customizations to the system level defaults file, so it can be used for site policies. It is recommended that implementations "hard code" the defaults as opposed to relying on the system file containing all definitions, and provide a means to support new options in future releases without changing the site specific values in the system defaults file.

Extended Options
For SVR4 or similar file system layout, distribution_source_directory may be set to /var/spool/sw. The use of this location is encouraged.

For SVR4 or similar file system layout, distribution_target_directory may be set to /var/spool/sw. The use of this location is encouraged.

For SVR4 or similar file system layout, installed_software_catalog may be set to /var/adm/sw/catalog. The use of this location is encouraged. The catalog may simply be a pathname of a directory where the database containing the catalog is stored, or may be a key into a directory service specifying a catalog in a file or database, or any other implementation-defined method of specifying a catalog. The location of the storage for the catalog itself is implementation defined.

The swinstall utility, and other utilities that operate on installed_software, modify the catalog information based on the outcome of the utility. Information contained within the catalog is resolved in the context of each target.

Originally, it was thought that a catalog would be kept as a flat file in a directory that could be specified using this option. In the interest of generality, so that implementors might be allowed to use databases, the catalog attribute is now described as a key. This allows an implementor to either use a flat file or a database or some other form of persistent storage for the information, yet still be able to separate the address space as desired. The motivation for permitting the separate address space stems from the following two cases. First, it seems desirable to allow ordinary (non-root) users to be able to use swinstall to store software in their own private space. Likely the only real restriction is a potential lack of write authority to the central storage for the catalog, hence the ability to create a separate catalog. This also allows a user to manage personal software with utilities such as swremove or other utilities. Second, installations may wish to deploy stable versions of their software in the normal location, and a test version installed in a second location where access may be more tightly controlled. There may even be other versions installed that are under development. Since this software may have identical attributes, it is desirable to allow such separate space for management. Both of these examples show the need for separate domains of software management.

Two values of autoselect_dependencies (.I "autoselect_dependencies=true" and autoselect_dependencies=as_needed) support different possible policies by the user. Having autoselect_dependencies=true ensures that all targets are kept in sync, while having autoselect_dependencies=as_needed prevents the possibility of updating dependency software to a higher revision unnecessarily.

Autoselection of a dependency across products is possible if a compatible product version with the highest revision that meets the dependency is unique. In other words, the same rules apply for dependency selection as for normal selection as described in Software Specification and Logic .

For the ask option, the checkinstall and configure scripts are required to detect needed response files when they are necessary, and return with the appropriate warning or error.

For the installed_software_catalog option, the catalog and the directory together form a key to identify one installed_software object. For example, this would allow the files on the file system to be split up into different management domains. For example, OS software, networking software, and application software could be in three different logical installed_software objects, although they are all installed under the root file system.

Extended Options Syntax
In the interest of having a single common extended option syntax for all the POSIX system administration standards, the following syntax was agreed upon. As of this writing, the syntax is a superset of that used by this Software Administration specification, IEEE P1387.3, and IEEE P1387.4.

%token          FILENAME_CHARACTER_STRING /* as defined in  */
%token          NEWLINE_STRING            /* as defined in  */
%token          PORTABLE_CHARACTER_STRING /* as defined in  */
%token          SHELL_TOKEN_STRING        /* as defined in  */
%token          WHITE_SPACE_STRING        /* as defined in */

%start  sysadmin_option

sysadmin_option          : qualifier option operator_value

qualifier                : compulsory_qualifier command_qualifier

compulsory_qualifier     : /* empty */
                         | '-' | '='

command_qualifier        : /* empty */
                         | command '.'

option                   : keyword op_ws

operator_value           : '=='
                         | value_qualifier '=' value

value_qualifier          : /* empty */
                         | '+' | '-'

value                    : op_ws value ws single_value
                         | op_ws single_value

single_value             : value_structure
                         | SHELL_TOKEN_STRING

value_structure          : '{'  op_ws value_list op_ws '}'

value_list               : /* empty */
                         | value_list ws single_value
                         | single_value

command                  : FILENAME_CHARACTER_STRING

keyword                  : SHELL_TOKEN_STRING

op_ws                    : /* empty */
                         | ws           

ws                       : WHITE_SPACE_STRING

%start command_line_options

command_line_options     : command_line_options ws sysadmin_option
                         | sysadmin_option

%start options_file

options_file             : options_file NEWLINE_STRING option_file_line
                         | option_file_line

option_file_line         : op_ws op_comment
                         | op_ws sysadmin_option op_ws op_comment

op_comment               : /* empty */
                         | '>' PORTABLE_CHARACTER_STRING


  1. A - (hyphen) qualifier indicates a compulsory behavior while = (equal) indicates a non-compulsory behavior.

  2. For options that support multiple values, values can be added to the existing list of values by using the += (plus equal) operator. Similarly, values can be removed by using the -= (hyphen equal) operator. Any option can be set to the default value by using the == (equal equal) operator and value combination.

  3. A shell token can be an unquoted or quoted string according to the rules of token recognition rules described in POSIX.2 section 3.3 (token recognition). For example, it can use single or double quotes and can contain like quotes if escaped with backslash. It can also support the same level of internationalization as the POSIX shell.

  4. The multiple value convention is consistent with white space separating tokens in commands (operands) and allows commas to be used in the single_value. This also allows multiple values to be specified without using quotes (although quotes are still needed for multiple values on the command line).

  5. If the extended option specification contains any white space at all, then the entire specification shall be quoted if used on a command line. This is because the -x option, which conforms to POSIX.2, requires exactly one value that is then processed using the above syntax.

  6. When specified on the command line, multiple option specifications can be included after a single -x option if included in quotes and separated by spaces. Multiple -x options may also be used.

  7. For option and defaults files, blank lines and all comment text [any sequence of characters beginning with an unescaped > (pound) and continuing through the end of that line] are ignored according to the shell token recognition rules as described in POSIX.2 section 3.3.

Precedence for Option Specification
The first rule defines typical precedence of system defaults, then a user defined set of defaults, then per task exceptions or specifications. The second rule supports normal use models of defining multiple "sets" of target_selections and software_selections, and being able to operate on the union of those sets. Also, the -f and -t options are simply another form for specifying operands, and are at the same level of precedence, and are thus combined with other selections. The third rule is generally an error, and the behavior is undefined (that is, it may be an error, or an implementation may chose to implement last- or first-wins). For example on HP-UX:
$ cc -O -g x.c $ cc: warning 414: Debug and Optimization are mutually exclusive. -g option ignored. $ cc -g -O x.c $ cc: warning 414: Debug and Optimization are mutually exclusive. -O option ignored.

It might be convenient to have a mechanism to allow the system administrator to define a default in the system defaults file that cannot be overridden by a user. Such a function may be supplied by an implementation as an extension. This may also be considered as part of a future revision to this Software Administration specification.

Standard Input
No additional rational is required under this heading.
Input Files
No additional rational is required under this heading.
Access and Concurrency Control
If the installed_software_catalog is referenced by a path on the file system, then the user can create a catalog in their own user work space (creating their own installed_software object), and install and manage software in that installed_software object.

If the catalog is stored in a file, then a corresponding ability to create an installed_software object (and thus, a catalog) is needed.

Access control includes such things as requiring particular authority to operate on particular software or software_collections. Concurrency control is the prevention of more than one writer at a time to the catalog or data areas. Restrictions to prevent multiple concurrent writers were originally part of the draft, but later determined to be excessively restrictive. It is conceivable that more than one writer could safely be active at a time if the work involves no common files. Failure to allow multiple concurrent readers of the catalog, or other data files, is strongly discouraged.

There are two aspects to access control as follows:

For access control to the files themselves, this Software Administration specification defaults to the file permissions defined by POSIX.1. File attributes are defined for the files, hence the implementation will set the POSIX.1 file permissions based on those values. Deviations from this model are permitted only for implementations running on file systems that are not POSIX.1 conformant, and then only as long as the implementation documents the resulting behavior.

Any additional access control to the software objects defined in this Software Administration specification (for example, permission to install specific software into specific software collections on specific hosts), is undefined. An implementation may choose to have no access control. For example, anyone may install any software to any system as long as the previous POSIX.1 file permissions are satisfied. An implementation may also choose to provide both authorization and authentication for access to all software objects and hosts, as well as a distributed interface for managing the access control lists.

Like the definition of the model to implement distributed aspects of this standard, access control beyond that required by the underlying operating system is undefined. It was determined that both of these rely on technologies that have not been formally standardized, and may better be addressed in other forums.

External Effects

Control Script Execution and Environment
The provision for interpreters other than sh was requested by users among the developers of this Software Administration specification, as well as producers representing systems that might lack a POSIX.2 or even POSIX.1 operating system. By making this provision, many felt that a greater degree of acceptance and usefulness could be gained.

The restrictions placed on the option syntax are such that each of the options can be easily parsed and hence set by a control script by simply sourcing the file. The term "sourcing" as used here implies the use of the "." command in the POSIX.2 shell. For example, the following are formats for the SW_SESSION_OPTIONS file that can be sourced:

loglevel=1 enforce_dependencies=false software="A B C" loglevel=1 enforce_dependencies=false software=" A B C"

It is possible for the scripts to determine the loglevel for the command from the file pointed to by SW_SESSION_OPTIONS, and use that to affect the amount of stdout generated.

An implementation may have an implementation-defined user controllable behavior that invokes error handling procedures in the case of warnings returned from script execution.

The purpose of the environment variables is to pass vital information to the scripts so that they may operate appropriately under different circumstances. For example, they may want to take very different actions when SW_ROOT_DIRECTORY is some value other than /. It has also been discussed that there may need to be some way to pass other information to these scripts such as option values specified in the defaults and options file that control policy. This can be achieved with the SW_SESSION_OPTIONS variable, which points to a file containing all the options passed to the command, including options, selections, and targets.

One reason that this Software Administration specification differentiates install and remove scripts from configure scripts is to separate installing software from configuring software for actual use. This supports installing software to alternate root directories on servers for use by clients that configure that software.

The developers of this Software Administration specification also discussed, but did not include, the use of several of these variables for setting the value of specific utility options when the utilities are called from control scripts. These variables are as follows:

Could be used to specify the directory portion of all target operands.

Could be used to specify productlocation portion of all software_selection operands.

Could be used to specify the value of the installed_software_catalog option.

The scripts need to be aware of the environment under which they are operating. The environments that these scripts run under are as follows:

Control Script Behavior
Control scripts allow vendors to perform tasks and operations, in addition to those that the tasks perform. The swinstall, swverify, and swremove utilities may each execute one or more vendor-supplied scripts. The presence of these scripts in the distribution is optional. Vendors of software to be installed need only provide those scripts that meet a particular need of the software. The following summarizes the standard scripts:

request (Request script)

This is the only script that may be interactive. This script may be run by swask, swinstall, or swconfig after selection, and before the "analysis" phase in order to request information from the administrator that will be needed for the configure script when that script is run later.

This script is executed on the manager role and it is the responsibility of the script to write all information into the response file in the directory where the script is being executed (the SW_CONTROL_DIRECTORY). The utilities will then copy this file to the SW_CONTROL_DIRECTORY on the target role where the configure and other scripts are executed from. This response file may be used by any other scripts, but particularly the configure script.

A recommended syntax for the response file is a set of attribute-value pairs that can be easily sourced by the configure script. For example, a request script might look like the following:

echo "Enter path to locate the database" read $path echo db_path=$path >> $SW_CONTROL_DIR/response

and the using configure script:

$db_path=$default_db_path if [ -f $SW_CONTROL_DIR/response ] then . $SW_CONTROL_DIR/response fi create_db ( $db_path )

response (Response file)

The response file is generated by the request script and located in the same directory as that and the other scripts. The format and content of the response file is vendor defined. For example, it may be a list of environment variable definitions so that the consumer script can just source this file.

checkinstall (Install check script)

This script is run by swinstall during the "analysis" phase in an attempt to ensure that the installation (and configuration) succeeds. For example, the OS run state, running processes, or other prerequisite conditions beyond dependencies may be checked. Running this script shall be free of side-effects, for example,for example, processes may not be killed, files may not be moved or removed, etc.

preinstall (Install preload script)

This script is run by swinstall prior to loading the software files. For example, this script may remove obsolete files, or move an existing file aside during an update.

This script and the next script are part of the "load" phase of the software installation process. Within each product, all preinstall scripts are run (order is dictated by any prerequisites), all filesets are loaded, then all postinstall scripts are run.

postinstall (Install postload script)

This script is run by swinstall after loading the software files. For example, this script may move a default file into place.

unpostinstall (Recovery postload script)

This script is run by swinstall before restoring the software files if the postinstall script has been run. It can be used to undo the actions of the postinstall script.

unpreinstall (Recovery preload script)

This script is only run by swinstall after restoring the software files if the preinstall script has been run. It can be used to undo the actions of the preinstall script.

verify (Verify script)

This script is run by the swverify command any time after the software has been installed or configured. Like other scripts it is intended to verify anything that the commands do not verify by default. For example, this script may check that the software is configured properly and has a proper license to use it.

fix (Fix script)

This script is run by the swverify command when the -F option is used. Its purpose is to correct any problems reported by the verify script.

checkremove (Remove check script)

The remove check script is run by swremove during the remove "analysis" phase to allow any vendor-defined checks before the software is permanently removed. For example, the script may check whether anyone is currently using the software.

preremove (Preremove script)

This script is executed just before removing files. It may be destructive to the software being removed, as removal of files is the next step. It is the companion script to the install postload script (postinstall). For example, it may remove files that the install postload script created.

This script and the next script are part of the "remove" phase of the software remove process. Within each product, all remove preremove scripts are run (in the reverse order dictated by any prerequisites), all files are removed, then all remove postremove scripts are run.

postremove (Postremove script)

This script is executed just after removing files. It is the companion script to the the install preload script (preinstall). For example, if this was a patch fileset, then the install preload script may move the original file aside, and this remove postload script may move the original file back if the patch was removed.

configure (Configure script)

This script is executed by swinstall after all software has been installed (including loading files and running postinstall scripts) if software is being installed at /. It is also may run by swconfig, even if the software has already been configured (allowing the administrator to reconfigure software).

unconfigure (Unconfigure script)

This script is executed by swremove before any software is removed (including removing files and running preremove scripts), if removing from software installed at /. It is may also be run by swconfig.

Other scripts

The vendor may include other control scripts, such as a script that is sourced by the above scripts, or scripts not defined in this Software Administration specification. The location of the control scripts is passed to all scripts via an environment variable SW_CONTROL_DIRECTORY.

Control Script Return Code
This Software Administration specification only specifies return codes from scripts that affect operation of the utilities. If the script writer wants to convey additional information to the user, such information should be written to stderr or stdout, which gets recorded by the target role logging. See Logging .

A implementation that supports additional behaviors may initiate those behaviors based on implementation-defined return values from control scripts.

Asynchronous Events
Control script execution and file operations only generate note events at the beginning of the step, not at both the beginning and the end. This is because there is an event immediately after each script or file completes (for example, the next file beginning, or the end of fileset execution). Additionally, if there is any error with the script or file, there is a warning or error event generated after the file completes.
No additional rational is required under this heading.
There is a variety of warnings and errors that could occur at the target role. It is desirable that this information be communicated back to the management role and displayed on stderr of the management role. Of course the detail of the information is determined by the verbose level. However, since this Software Administration specification does not specify the communication mechanism between the management and target roles, it should not place unnecessary requirements on this communication mechanism, especially since this could be occurring in a distributed environment with the management role communicating with multiple target roles. Thus the only requirement here is that the target role be able to communicate a binary fail/success back to the management role.
For the management role, the information placed in the logfile is equivalent to the information sent to stderr and stdout if the verbose level was the same value as the loglevel.

The stdout, stderr, and logfile output should contain the severity of the event as part of the output message. For example:

NOTE: The analysis phase succeeded on target "zook:/". WARNING: Target "zook:/": 2 configure scripts had warnings.

Extended Description

Selection Phase
An implementation may define other valid source specifications, such as "well-known" sources that may be available via a directory service or an object request broker.
Analysis Phase
No additional rational is required under this heading.
Execution Phase
Figure: Fileset State Transitions (Within Distributions)

Fileset State Transitions (Within Distributions) and Fileset State Transitions (Within Installed Software) show the state transition diagrams for Installed Software and Distributions.

It is clear that some vendors may want additional states. But allowing other values would make it problematic for any implementation trying to make decisions on how to deal with filesets with unrecognized states. An implementation may create an additional fileset attribute that would further modify the meaning of the attribute. For example, they may create an attribute called state_info and this attribute may have the value of files_missing when the state attribute is set to corrupt. There could be several valid values of this new attribute to describe various possibilities of a corrupt state. Of course, since this would be an implementation-specific extension, other implementations would not need to recognize this attribute or its semantics.

The default for updating, downdating or removing a fileset is to remove the information from the catalog. However, implementations may instead set these filesets to have a state of removed.

The default behavior for filesets in the removed state is the same as for filesets that are "non-existent". Implementations that support the removed state should define extensions to the POSIX utilities providing operations on removed filesets. For example:

swlist -x show_removed=true

Figure: Fileset State Transitions (Within Installed Software)

Exit Status

No additional rational is required under this heading.

Consequences of Errors

Since the utilities in this Software Administration specification operate on multiple software objects for multiple targets, the handling of error conditions (which is basically a policy decision) is complex. For example, should success be only all or nothing; or only, if all operations succeed for a specific host; or only, if all operations succeed for a specific product on all hosts? The type of error or errors causing such definitions of success or failure is implementation defined. Whether or not the user may specify policies regarding the way in which errors are handled is also implementation defined.

Software Packaging Layout

Software to be distributed according to this Software Administration specification is represented in a form defined as the software packaging layout. The software packaging layout provides a standard for representing software using the exported form of the software catalog, and a structure for the actual software files.

The reason for specifying a standard software packaging layout is to allow for interoperable media. In other words, any conforming distribution may be read by any conforming implementation.

This layout does not dictate how the software files are actually located in the file system. The layout provides a portable means to store and distribute files for any file organization. Installing could involve a transformation from a canonical form to one that conforms to the requirements of the architecture of the machine on which the software is to run.

The software catalog refers to the information (metadata) that describes software objects in a particular distribution or installed software object. Each catalog describes exactly one software_collection (installed_software object or distribution).

The information in the software catalog may be created, altered, and removed using the utilities defined in this Software Administration specification. A system administrator may use swlist, for example, to obtain a list of installed software products, the shell scripts used for installing a product, or the files contained within a product.

Each system has a default catalog for installed_software. This catalog provides information on the products installed for use on that system. Permission to modify the catalog may be restricted to the system administrator. Since there are times when users without special privileges may wish to use software administration tools to install and maintain software in their parts of the file store, additional installed_software objects, in separate software catalogs, may be created and acted upon by any user having appropriate authority.

The way that installed_software catalog information is stored (whether kept in text files or databases, whether distributed or centralized), is undefined within this Software Administration specification.

Directory Structure

An implementation may want to support several levels of INDEX files. The global INDEX file shall contain the correct information, and other lower level INDEX files may be used for convenience of the implementation when building the global INDEX. The following INDEX files, when simply concatenated together, form the following global INDEX:

An example of product control directory name follows. If a product with the tag attribute value of SDU is added to a distribution, and no other objects with the same value of tag exist, the product_control_directory for storing the product object is SDU/. If another product object with the tag SDU is added to the distribution, the product_control_directory for that product object is SDU.2/. The first SDU product was assigned the value of 1 for its productinstance_id.

Software Definition File Format

Through the software definition files contained in this Software Administration specification, an exported catalog structure representation is defined within the context of a distribution. This is necessary to have interoperable media. It is also used to define an exported catalog structure representation for installed_software objects. This is necessary for swlist output.

In the PSF, attributes may be undefined or set explicitly unless their default value is none. Most attributes have a default value. Default values are logically required for attributes that may be optionally specified in the PSF.

Most Boolean attributes default to false, such as is_reboot, is_kernel, and is_locatable. Instead of defaulting all Boolean attributes to false through clever wording of the attribute tag, some default to true, such as is_locatable.

The distribution keywords and the layout_version specification should not be changed in future amendments to this Software Administration specification so an implementation can determine the version of the layout being used.

In the PSF, the < (less than) is a token for unambiguous parsing, but it does not imply that the file contents should be included (that is, file re-direction). The alternative is to take the file from that path on the development system and store it as a control_file (for example,for example, a copyright control_file containing that attribute).

Vendor-defined attributes include any attribute that has a keyword not defined by this Software Administration specification. Since the value of any vendor-defined attribute is interpreted simply as a string, the original value entered in the PSF is preserved through packaging and copy operations. The value is thus preserved until the package is finally installed. During installation, swinstall may be affected by vendor-defined attributes in the INDEX or INFO files and may choose to preserve or not preserve the associated values for such keywords. The swinstall utility is only required to preserve in the catalog those values that correspond to the keywords defined in this Software Administration specification. Refer also to portions of the extended description for the swinstall utility.

Since device file creation is not possible in a portable way (that is, not included in POSIX.1 or POSIX.2), only a configure script that is running on the target system can reliably create devices files. POSIX.1 does define the "syntax" of major and minor, so it is possible for the configure script to add these attributes via swmodify (and for swmodify to look up their values through POSIX.1 interfaces). This in turn allows swverify to verify that these are correct.

The extended file definition syntaxes provide a flexible interface to individual software vendor development and build systems. These build systems may contain files to be packaged existing anywhere from intermingled with source files to a target build tree containing the files in the locations they would be in after installation.

The following examples illustrate the use of the directory and file keywords:

  1. Include all files under /build/s/, to have a as /opt/sw:
    directory /build/s /opt/sw file *

  2. Include only certain files under /build/s/, to be rooted under /opt/sw:
    directory /build/s /opt/sw file bin/swinstall file -t h bin/swinstall bin/swcopy file -t d lib/nls file nls/ lib/nls/ file data/swinstall.defaults newconfig/defaults/swinstall file data/swinstall.defaults /var/adm/sw/defaults/swinstall

  3. Explicitly list files, no directory mapping specified:
    file /build/s/bin/swinstall /opt/sw/bin/swinstall file -t h /opt/sw/bin/swinstall /opt/sw/bin/swcopy file -t d /opt/sw/lib/nls/ file /build/s/nls/ /opt/sw/lib/

  4. Use all specification types to include files:
    directory /build/s /opt/sw file * file bin/swinstall file -t h bin/swinstall bin/swcopy file data/swinstall.defaults newconfig/defaults/swinstall file data/swinstall.defaults /var/adm/sw/defaults/swinstall

The following examples illustrate the use of the file_permissions keyword:

  1. Set a read-only 444 mode for all file objects (requires override for every executable file and directory):
    file_permissions -m 444

  2. Set a read mode for non-executable files, and a read/execute mode for executable files and for directories:
    file_permissions -u 222

  3. Set the same mode defaults, plus an owner and group:
    file_permissions -u 222 -o bin -g bin

  4. Set the same mode defaults, plus a uid and gid:
    file_permissions -u 222 -o 2 -g 2

  5. Set the owner write permission (in addition to the above):
    file_permissions -u 022 -o 2 -g 2

If the user defines no file_permissions, swpackage uses the default value:

file_permissions -u 000

for destination file objects based on existing source files. This means that the mode, owner/uid, and group/gid are set based on the source file, unless specific overrides are specified for a destination file.

The default value:

file_permissions -u 000 -o bin,2 -g bin,2

is used by swpackage for destination file objects being created (not based on existing source files).

If neither the path nor any attributes is specified, then the suggested default values of the attributes are:

-m 0777 -o bin,2 -g bin,2

These are only suggestions, since the default values in this case are implementation defined.

The space file is used to account for disk space used (positive size) or freed (negative size) by control script execution. Negative sizes may be used by a more sophisticated disk space analysis that accounts for transient as well as final disk space. For example, if a fileset has a configure script that creates a 200 KB file /usr/foo/data/file, it can include a space file with the entry:

/usr/foo/data 200000

This will tell the implementation to add 200 KB to the disk space requirements. If the configure script moves a 35 KB file from /etc/file to /sbin/bin, it could include the entries:

/etc/file -35000 /sbin/file +35000

An implementation may choose to ignore the negative entry, producing a "worst case" disk space requirement. Alternatively, the implementation may choose to list the "worst case" requirement (ignoring the negative entry, reflecting the transient disk space required), and then the final disk space (accounting for the negative entry). Finally, if a configure script created a temporary 5 MB file under /tmp, it could add the entries:

/tmp 5000000 /tmp -5000000
The following are examples for "update packaging":

Example of type (x):
file -t x /oldfile

This adds a remove file to the fileset definition. It gives the software packager explicit control over which files to remove (useful if any of the files from previous revisions were user configurable).

Example of ancestor
product tag NEWPROD fileset tag NEWFILESET ancestor OLDPROD.OLDFILESET,r=10.0

This designates NEWPROD.NEWFILESET to be included in the list of filesets generated by the match_target option to swinstall if OLDPROD.OLDFILESET has been installed.

Example of supersedes
product tag NEWPROD fileset tag NEWFILESET supersedes OLDPROD.OLDFILESET,r=10.0

This designates that installing NEWPROD.NEWFILESET will result in removing the catalog information for OLDPROD.OLDFILESET.

Patch Packaging
If the patch uses the same product tag and fileset tag as the fileset it is patching, then no ancestor is necessarily needed. But, unless this patch patches all previous releases of the base fileset, an ancestor must be specified. If the patch has a different product and fileset tag than the fileset it patches it must also have an ancestor.

A unique product revision must be specified for a patch fileset if that patch has the same product tag and fileset tag as the fileset it is patching.

If this is the first patch of any particular patch stream, then it does not need a supersedes attribute. This is true for all original point patches. If this patch replaces one or more other patches, then it must specify the appropriate supersedes attribute.

All patch software objects with the is_patch attribute automatically have the built-in patch category included in the list of category_tags.

A fileset that has the is_patch attribute will not update a fileset with the same tag as is done with normal filesets. In the case of filesets with is_patch set to true, the "revision" is now a version distinguishing attribute at the fileset level.

The category_tag and is_patch attributes at all other levels of software objects besides fileset are for display and selection purposes only. These attributes are not version distinguishing attributes.

The 1387.2 developers discussed whether patch verification capabilities could be defined that might help the quality of patches, but concluded that this would be outside the scope of their task.

Library/Kernel Patching
In order to patch an archive library, a new file type designed for archive library maintenance is supported. The "file" specification for a .o file also includes the library in which the file is to be placed (using ar).

file -t a -a /usr/lib/foolib.a /build/newfile.o \ /usr/lib/newfile.o file type a archive_path /usr/lib/foolib.a source /build/newfile.o path /usr/lib/newfile.o

Serial Format and Multiple Media

The 1387.2 developers discussed the desire for system vendors to have both a boot partition and the serial archive distribution containing the operating system software on a single medium. Numerous strategies were discussed, but no solution could be found that met all the disparate boot strategies. Vendors that have this need may need to create nonconforming media that have both the boot partition and the distribution on the media. They should then copy that distribution into a conforming form.

Separate archives on each medium allows the swinstall utility to only request the needed medium (via the media_sequence_number), without having to scan each one sequentially. The rule concerning a fileset being in one archive is needed so the swinstall utility knows whether to request the next medium when it reaches the end of the current archive.

When packaging a product that contains kernel or prerequisite filesets onto a serial media, swpackage should put the filesets on the serial media in the same order in which they will be requested by swinstall in order to minimize media rewinds. If the packager and install utilities used are from different implementations, then the amount of rewinds dramatically increases. One possible ordering convention is as follows:

  1. Order all products alphabetically by their product tag (and as they are encountered for multiple versions of the same product). Order all filesets alphabetically within each product. This results in the initial ordering for all filesets.

  2. Traverse the list front to back, moving all kernel filesets to the front of the list in their same relative order to each other.

  3. For each fileset, determine all of the prerequisite dependents for that fileset, meaning filesets that have a prerequisite on this fileset, or a prerequisite on an object containing this fileset. Traverse the list back to front, moving each fileset in front of the first of its dependents in the current list order, considering dependencies across products and chaining of prerequisites as follows:

  4. Traverse the list front to back, determining a new product order as each new product is encountered. The filesets within each product are also ordered by traversing front to back.

  5. Using this product order, place all product catalog files on the serial media; then place all kernel filesets from each product on the serial media (including the prerequisites of kernel filesets); then place all non-kernel filesets from each product on the media.

When installing filesets, use this same order to load kernel filesets before non-kernel filesets, and to load prerequisites before their dependents.

Additional files besides just those for the distribution may be needed on distributions. For example, a software vendor may want to include a copy of the swinstall utility on the media.

Software Administration Utilities

The following discussion on the approach of the 1387.2 developers to defining each software administration utility is presented in the same reference manual page style as that used in Software Administration Utilities for the actual definition of these utilities.


Object classes are templates for the creation of object instances. They are analogous to the definition statements used in programming languages to define data structures that will be created later. Objects contain more than data structures, in that they also possess methods (procedures that are executed by objects). A well-formed object class has methods defined that handle all object data manipulation, including creation, modification, and listing, so that the actual storage of the data is appropriately hidden from the application using the objects.

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