Background Information

General

Scope and Purpose

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.

Roles

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:

• Proxy install (installing on one system for use by another system) where configuration of the software is done separately, because the target may not have the necessary capabilities or information, or both, for configuring the client.

• The target is a file server, and there are multiple clients that access the software installed on the file server. Each client may require separate configuration as targets of swconfig.
  

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.

Tasks

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

Customer update requirements for software updates were perceived as follows:

• Ability to update a previous release with a new release with the same reliability, performance and resultant functionality as installing the new release for the first time, at the same time preserving any customer data or configuration information.

• Automatic selection of the most recent release, or manual selection of previous releases.

• For network distribution, do not necessarily redistribute files from the new release that have not changed.

• Record that the previous release has been updated (that is, no longer exists) in the installed software database.

• As an alternative to in-place updates, support multiple releases of software on a system, letting the user choose which one to use.

• Goal of no down time while upgrading.

• Support automatic rollback to the previous release if the installation fails.

• Ability to store multiple releases of multiple architectures of software in the same depot.

• Easy identification of different releases of the same software.

Provider update requirements for software updates were perceived as follows:

• Ability to easily repackage and redeliver a software update.

• Ability to have a single package that supports both new installs and update of previous installs.

• Easy management of customer data and configuration information.

• Ability to deliver multiple releases of software in the same distribution.

• Provide for automatic removal of obsolete files from the release that has been updated.

• Ability to have a "sparse" update, where only a subset of the files in a fileset is updated, but the result is the same as a full update.

Patch Requirements

Customer patch requirements were perceived as follows:

• Ability to store patches in the same depot as other software.

• Easy identification of available or installed patches and of what filesets have been or can be patched.

• Automatic installation and copying of patches along with their base filesets.

  • Allows installation/copying of patches in the same session as the base software, or during cold install.

• Improve patch installation performance over script based patches.

• Make patch selection easier by allowing selection of patches based on criteria (categories).

  • Criteria could cover categories such as severity, quality, and special cases such as hardware enablement.

• Provide for automatic removal of patches when software is updated, downdated, reinstalled or removed.

• Allow automatic selection of patches matching the installed software on target.

  • Installs/copies patches matching software installed on target system (or in target depot).

  • Criteria categories provide additional control over selection.

• Allow rollback of patches and automatic restoration of previous versions of patched files.

  • Switchable rollback capability.

  • No special scripts required.

• Provide a mechanism for patch commit. "Commit" of a patch removes rollback information (recovers disk space used to save previous file versions).

• Ability to list what files will be updated.

• Ability to find out what problems will be fixed by this patch.

Patch provider and support organization requirements were:

• Simplified native patch structure, improved reliability.

• Faster patch production.

• Ability to deliver patches on a single distribution media along with base software.

• Integrate "reasonably" into current patch processes; support both point patches and new patches superseding one or more previous patches; support patching of libraries.

• Support patching of multiple releases.

Conformance

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 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

Conforming POSIX.2 Distribution

Conforming POSIX.2 Distribution Using Extensions

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

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:

distribution

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.

installed_software

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:

product

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.

bundle

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

fileset

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.

subproduct

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_file

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).

file

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 classes¹.

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.

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

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 .

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

distributions

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.

host

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.

installed_software

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.

machine_type

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.

os_name

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.

os_release

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.

os_version

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.

Software_Collection

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.

Distribution

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.

tag

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

title

A longer name used for display purposes.

description

A more detailed description of the contents of the distribution.

revision

A revision associated with the distribution.

media_type

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

copyright

The copyright notice for the distribution.

create_time

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

number

The vendor part number for the distribution.

architecture

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.

Media

Installed_Software

Vendor

Category

Software

This standard has defined four related software objects:

• Products

• Filesets

• Bundles

• Subproducts

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:

• Products and filesets are concepts firmly entrenched in existing practice. All of the many practices that have contributed to this standard have included these two levels. Manageable software objects necessarily includes some files to manage. This is the basis of a software product. Additionally, most application software has both required and optional pieces, so often only a subset of the product may be installed. Thus, a fileset is chosen as a "set of files" and a product is a collection of filesets that have a number of shared attributes, and are distributed in a single distribution (usually from a single vendor).

• It was agreed that a "recursive notational convenience" was very desirable. Additionally, many (but not all) existing practices had realized the need for various overlapping groupings of software into new "configurations." Bundles and subproducts are merely "macro" or "recursive" products and filesets, respectively. Just as products and filesets are a bit different, the use of bundles and subproducts are a bit different. Bundles provide a way to make products out of existing products or parts of products. Subproducts provide a way to provide selectable units that may overlap in fileset contents. For example, a fileset may be part of "runtime" support as well as "development" environment subproducts. Finally, bundles and subproducts are recursive in that they may contain other bundles and subproducts, respectively.

• The containment of filesets and subproducts within products allows for derived naming of components of a product - that is, a simple tag for a component relative to a more complex name (.I tag , revision, vendor_tag, architecture) for a product. In addition, this leads to distributions with a simple directory structure for filesets within products.

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:

 

keyword.<LANG>

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.

Products

 

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

 

os_name sunos
os_rev 4.1.*
os_ver *
machine_type sun4*

 

architecture hp-ux_9_pa-risc

 

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 product.directory attribute should be set to /appl . If a user relocates the product with a command like:

 

swinstall appl,r=1.0,l=/disk2/appl

 

swinstall appl.console,r=1.0,l=/disk1/appl
swinstall appl.agent,r=1.0,l=/disk2/appl
swinstall appl.data,r=1.0,l=/disk3/appl

 

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 appl.data,r=1.0,l=/disk3/appl,q=current

 

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:

• Fileset to fileset within a product.

• Fileset to (some other) product.

• Fileset in one product to fileset in another product.

• Product to product.

• Product to fileset in some other product.

• Product to fileset in that product (essentially mandatory fileset).

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

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.

Filesets

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.

Example:

 

supersedes   product.fileset,r<revision

Subproducts

Software_Files

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:

• Built-in knowledge of the compression_type format for compressing and uncompressing

• The product control directory for a program named in compression_type

• PATH on the target system for a program named in compression_type

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:

• A new archive_source attribute to indicate that the file contents are within a named archive.

• Defining a new fileset archive_type attribute with values of empty string, cat, or the name of an archive routine like tar. The type cat indicates simple appending to an archive file. If cat (or even possibly tar ) were used, an archive_offset attribute would indicate where within the archive the file started. This could be used for fast single-file extraction using either size or compressed_size.

• Extended options on swcopy for archive_files and archive_type (similar to compress_files and compression_type). The uncompress_filestrue option on swcopy would both unarchive and uncompress.

• An archiver interface that permitted appending or extracting one file at a time.

• The archiver, like the compressor, could be distributed in the product control directory.

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.

Files

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

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

Synopsis

Description

Options

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

Operands

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

 

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:

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 product.directory 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

 

software_collection_spec   : [ host ] [ ':' ] [ path ]

Examples of distribution software_collection_specs are:

 

/var/spool/sw
hostA
hostA.cloneinc.com
hostA:/var/spool/sw
15.1.94.296
15.1.94.296:/depots/applications

Examples of installed_software software_collection_specs are:

 

/
hostA
hostA.cloneinc.com
hostA:/
15.1.94.296
15.1.94.296:/exports/applications

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

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_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

%token          FILENAME_CHARACTER_STRING /* as defined in 2.2.2.37  */
%token          NEWLINE_STRING            /* as defined in 2.2.2.61  */
%token          PORTABLE_CHARACTER_STRING /* as defined in 2.2.2.68  */
%token          SHELL_TOKEN_STRING        /* as defined in 2.2.2.80  */
%token          WHITE_SPACE_STRING        /* as defined in 2.2.2.110 */

%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
                         ;

Notes:

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

 

$ 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

Input Files

Access and Concurrency Control

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:

• Those related to file system access and hence determined by the operating system (that is, the ability to write the files described by the sofware file objects).

• Any additional access control on the software objects, including access to (possibly remote) software collections.

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 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:

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

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

SW_CATALOG
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:

• All scripts

  Each script shall be passed its script tag, the root directory to which installing, the product directory where the product is located, and the control directory where the script is being executed from, as the environment variables SW_CONTROL_TAG, SW_ROOT_DIRECTORY, SW_LOCATION, and SW_CONTROL_DIRECTORY, respectively.

• preinstall, postinstall, preremove, postremove, unpreinstall, unpostinstall

  The install and remove scripts are run when loading or removing the software, or when recovering from a failed install. These may be executed by swinstall or swremove running on a host with a different architecture from the software. So, only the set of POSIX.2 utilities are guaranteed to be available on the server. Since the architecture of the file server is not necessarily known, the path to these commands is passed to the scripts via the environment variable SW_PATH.

  Additionally, these scripts need to know the alternate root directory so that operations are within the context of that root, not the root of the file server. (This directory is supplied to the scripts via an environment variable SW_ROOT_DIRECTORY.) It is critical that SW_ROOT_DIRECTORY is honored by these scripts.

• checkinstall, checkremove, verify

  It is expected, but not assumed, that these scripts mostly check the state of a system that will actually run the software. For the install check (checkinstall) script, again only a minimum set of commands is guaranteed to be available. This is because all check scripts are executed before any new software is installed. For the remove check and verify scripts (checkremove and verify), files from this software and its prerequisites are guaranteed to be available.

  Because of alternate root installation, these scripts also need to be aware of the SW_ROOT_DIRECTORY.

• configure, unconfigure

  These scripts configure the system for the software. Therefore they can run architecture specific commands, including files that are part of the software that defines the scripts. They are only run within the context of the system that will actually use the software. The SW_ROOT_DIRECTORY will always be /.

Control Script Behavior

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

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

Asynchronous Events

Stdout

Stderr

Logging

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

Analysis Phase

Execution Phase

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

Exit Status

Consequences of Errors

Software Packaging Layout

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

• catalog/dfiles/INDEX
  A distribution INDEX contains the definition of the attributes set for the distribution itself and the bundle definitions.

• catalog/<product_control_directory>/pfiles/INDEX
  A product INDEX contains the definition of the product and subproduct attributes for the product object that product_control_directory represents.

• catalog/<product_control_directory>/<fileset_control_directory>/INDEX
  A fileset INDEX contains the definition of the fileset attributes for the fileset object that fileset_control_directory represents.

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

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 directory mapping is intended for use with target build trees where all files are below a build root. The build root maps to some directory in the installed location such as / or some subdirectory like the product_control_directory.

• Recursive (implicit) file specification can be used with the previous instead of explicitly defining each file. In this case the mapped directory shall contain only the files from that particular fileset, and shall map to some directory (for example, /) on the installed system.

• Explicit file specification is useful for build systems where files are not organized in the same way they are to be installed, and for build systems that want the control of listing each file explicitly (implicit specification could possibly lead to unwanted files being packaged).

• Packaged files, by default, take the permissions of the files being packaged. Specification of permissions override the permissions of the files being packaged. Alternatively, each file may have its permissions explicitly defined.

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

1. Include all files under /build/s/, to have a product.directory 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/swinstall.cat lib/nls/swinstall.cat
   
   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/swinstall.cat /opt/sw/lib/swinstall.cat
   
   
   

   
   

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

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

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

Example:

 

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

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:

   • If the first dependent is in the same product, move the fileset just in front of that dependent.

   • If it is in a different product, move it in just in front of all filesets in product that contains the dependent.

   • If a fileset A depends on B which depends on C, move the filesets in C in front of A.

   • Leave the fileset where it is if there are no dependents.

   • Do not move any fileset more than once. Note that circular prerequisites will cause at most two moves, possibly resulting in the original order.

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

Footnotes

1.

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.