The UNIX 98 brand, introduced with the Single UNIX Specification, Version 2, includes a new
Component Definition defined by IEEE Std. 1387.2-1995, Software Administration (POSIX-7.2).
The UNIX 98 Software Administration Component enables software packagers to package software into a single distribution for multiple platforms, and to define relationships between software components which can range from simple to complex. For example, software packages can be a simple set of files, an application, or a bundle of related applications. This also provides the administrator with a consistent way to distribute, install, and control software (including listing, verifying, reconfiguring, and removing). Software providers and administrators will no longer have to write their own tools and repackage software for use with these tools.
The packaging, distribution, and control of software is an important and time-consuming task for software developers and administrators. In order to manage software in a distributed, heterogeneous environment, both software developers and administrators have often been required to develop their own management tools.
Software developers are currently faced with one of two choices. They can develop their own installation procedure and port it to each of their target platforms, or they can design different installation procedures for each target platform using the formats and procedures supported by that platform.
Administrators in heterogeneous environments often resort to defining their own tools so that they have a common way to manage software across all of their systems. Even though comprehensive software management solutions are becoming more prevalent in the market, many of these solutions require repackaging the software into a supported format.
The original work going into POSIX-7.2 focused on UNIX systems. Over the course of development, the standard was broadened to permit implementation by other operating systems, including those for personal computers.
The scope of POSIX Software Administration can be viewed in two ways: the components of the standard from a functionality point of view, and the various roles that operate on software from the time it is developed to its execution by end users. These are presented next.
There are three main components that the standard addresses:
The standard defines a hierarchical set of structures that the software developer can use to organize software files into manageable components. These structures can be built to reflect both purchasing options and installation options ranging from the simple to the complex.
The standard also defines the layout of the distribution media containing packaged software. This provides portability of installation media, as the media can be processed by any conforming system. Both serial and directory access formats are defined so that a wide range of media can be supported using the same layout.
By providing an interface for software administration that is consistent for all conforming implementations, administrators are able to use any such systems without retraining. Additionally, this greatly simplifies the installation documentation that software developers need to provide, as they can point to standard interfaces.
The standard provides utilities to package software files into distributions using the software packaging layout. There are utilities to install the software from the distribution onto target systems, and then manage that software once it is on the system. There are also utilities to manage the distributions themselves, including distributing software between systems.
Inventory information about the distributions is maintained both within the distribution as well as on the system after the software is installed. This information is stored in a software catalog, and is used to drive the management utilities. These management utilities include listing, verifying, or removing software. Thus, once the software package is defined, there are utilities to manage it throughout the software lifecycle.
The standard defines the concepts and the utility syntax for managing software in a distributed environment. An implementation of the standard can either provide the fully distributed utilities as defined in the standard, or provide limited conformance, meaning only local, or stand-alone, operations are supported. In order to understand the distributed aspects of the standard, it helps to present the distributed roles provided in the POSIX-7.2 rationale.
POSIX-7.2 roles can be viewed as processes that take software from one state to another; for example, from the form it has when it is in a distribution, to the form it has after installation.
In a distributed environment, each of these roles can be on a separate system, although for local operations they would obviously all be on the same system.
The developer role is specifically outside the scope of the standard.
In the developer role, software is constructed into the form
known as
developed software
which is the form in which it can be accepted by the packager role.
Typically, the developer role involves activities such as
compilation, source control, and so on.
The manager role provides for the distributed control of the software administration process. The manager role is where the POSIX tasks are initiated, and is the role with which the administrator directly interacts, either through the command line interface provided in the standard or through a management application. The manager role directs the other roles to actually package, install, or manage software.
The packager role transforms software from the locations where it exists after being developed into the standard packaging layout suitable for distribution. The packager role can package directly to media, or can package to file system-based distributions that can later be copied to media, or from where installation can be directly performed.
The source role serves the files in the software distribution source to the target role for actual installation onto a target system, or for copying to a second distribution. The source role also makes the logical software structures available to the manager role for user selection of software to be operated on.
It is the target role that actually installs the software and places it into a form from which it will eventually be used. Normally, the software is installed on the system where the software is run, in which case, the software is also configured. Note that, while this may be the usual case, the target role is not necessarily on the system that will run the software, but instead may be on a file server that serves the installed software to other client systems.
The client role is where the software is configured so that it is in a state where it can be executed. Configuration usually needs to take place on the system and architecture on which the software is to run, so the standard supports configuration independent of installation. Installed software may be subject to being configured several times. How the installed software is made available to the client role (for example, via a remote filesystem) is also outside the scope of the POSIX standard. In addition to making the installed software files available to the client, an implementation must also make the installed software catalog information available so that the clients can be configured by running configure scripts (described below).
Read or download the complete Single UNIX Specification from http://www.UNIX-systems.org/go/unix.
Copyright © 1997-1998 The Open Group
UNIX is a registered trademark of The Open Group.