The UNIX 98 brand, introduced with the Single UNIX Specification, Version 2, includes a newComponent Definition defined by IEEE Std. 1387.2-1995, Software Administration (POSIX-7.2).
The UNIX 98 Software Administration Component enables softwarepackagers to package software into a single distribution for multipleplatforms, and to define relationships between software componentswhich 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 todistribute, install, and control software (including listing, verifying,reconfiguring, and removing).Software providers and administrators will no longer have towrite their own tools and repackage software for use with these tools.
The packaging, distribution, and control of software is an importantand 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 requiredto 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 oftheir target platforms, or they can design different installationprocedures for each target platform using the formats and proceduressupported by that platform.
Administrators in heterogeneous environments often resort to definingtheir own tools so that they have a common way to manage software acrossall of their systems.Even though comprehensive software managementsolutions are becoming more prevalent in the market, many of thesesolutions 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 broadenedto permit implementation by other operating systems, including thosefor personal computers.
The scope of POSIX Software Administration can be viewed intwo ways: the components of the standard from a functionalitypoint of view, and the various roles that operate on software fromthe 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 thatthe software developer can use to organize softwarefiles into manageable components.These structures can be built to reflect both purchasingoptions and installation options ranging from the simple to the complex.
The standard also defines the layout of the distribution mediacontaining packaged software.This provides portability of installation media, as the mediacan be processed by any conforming system.Both serial and directory access formats are defined sothat a wide range of media can be supported using the same layout.
By providing an interface for software administration thatis consistent for all conforming implementations, administrators areable to use any such systems without retraining.Additionally, this greatly simplifies the installation documentationthat software developers need to provide, as they can point tostandard interfaces.
The standard provides utilities to package software filesintodistributions using the software packaging layout.There are utilities to install the software from thedistribution onto target systems, and then managethat software once it is on the system.There are also utilities to manage the distributionsthemselves, including distributing software betweensystems.
Inventory information about the distributions is maintained bothwithin the distribution as well as on the system after thesoftware is installed.This information is stored in a softwarecatalog, and isused to drive the management utilities.These management utilities include listing, verifying, orremoving software.Thus, once the software package is defined, there are utilitiesto manage it throughout the software lifecycle.
The standard defines the concepts and the utility syntax formanaging software in a distributed environment.An implementation of the standard can eitherprovide the fully distributed utilities as defined in thestandard, or providelimited conformance, meaning onlylocal, or stand-alone, operations are supported.In order to understand the distributed aspects of thestandard, it helps to present the distributed rolesprovided in the POSIX-7.2 rationale.
POSIX-7.2 roles can be viewed as processes that take softwarefrom one state to another; for example, from the form it haswhen it is in a distribution, to the form it has after installation.
In a distributed environment, each of these roles can be on aseparate system, although for local operations they would obviouslyall 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 formknown asdeveloped softwarewhich is the form in which it can be accepted by the packager role.Typically, the developer role involves activities such ascompilation, source control, and so on.
The manager role provides for the distributed control of thesoftware administration process.The manager role is where the POSIX tasks are initiated, andis the role with which the administrator directly interacts,either through the command line interface provided in thestandard 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 whereit exists after being developed into the standard packaginglayout suitable for distribution.The packager role can package directly to media, or can package to filesystem-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 sourceto 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 tothe manager role for user selection of software to be operated on.
It is the target role that actually installs the software andplaces it into a form from which it will eventually be used.Normally, the software is installed on thesystem where the software is run, in which case, the software isalso configured.Note that, while this may be the usual case,the target role is not necessarily on the systemthat will run the software, but instead may be on a file server thatserves the installed software to other client systems.
The client role is where the software is configured so that itis in a state where it can be executed.Configuration usually needs to takeplace on the system and architecture on which the software is to run, sothe standard supports configuration independent of installation.Installed software may be subject to being configuredseveral 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 availableto the client, an implementation must also make the installedsoftware catalog information available so that the clientscan be configured by running configure scripts (described below).
Read ordownload the complete Single UNIX Specification fromhttp://www.UNIX-systems.org/go/unix.
Copyright © 1997-1998 The Open Group
UNIX is a registered trademark of The Open Group.