This section defines IPS terms and describes IPS components.
IPS is designed to install packages in an image. An image is a directory tree, and can be mounted in a variety of locations as needed. An image is one of the following three types:
In a full image, all dependencies are resolved within the image itself, and IPS maintains the dependencies in a consistent manner.
Non-global zone images are linked to a full image (the parent global zone image), but do not provide a complete system on their own. In a zone image, IPS maintains the non-global zone consistent with its global zone as defined by dependencies in the packages.
User images contain only relocatable packages.
Images are created or cloned by installers, by the beadm and zonecfg commands, and by the pkg command with options such as --be-name.
Each package is represented by a Fault Management Resource Identifier (FMRI). The full FMRI for a package consists of the scheme, a publisher, the package name, and a version string in the following format:
scheme://publisher/name@version
The scheme for every IPS package FMRI is pkg. In the following example package FMRI for the suri storage library, solaris is the publisher, system/library/storage/suri is the package name, and 0.5.11,5.11-0.175.3.0.0.19.0:20150329T164922Z is the version:
pkg://solaris/system/library/storage/suri@0.5.11,5.11-0.175.3.0.0.19.0:20150329T164922Z
FMRIs can be specified in abbreviated form if the resulting FMRI is still unique. The scheme, publisher, and version can be omitted. Leading components can be omitted from the package name.
When the FMRI starts with pkg:// or //, the first word following // must be the publisher name, and no components can be omitted from the package name. When no components are omitted from the package name, the package name is considered complete, or rooted.
When the FMRI starts with pkg:/ or /, the first word following the slash is the package name, and no components can be omitted from the package name. No publisher name can be present.
When the version is omitted, the package generally resolves to the latest version of the package that can be installed.
A publisher is an entity that develops and constructs packages. A publisher name, or prefix, identifies this source in a unique manner. Publisher names can include upper and lower case letters, numbers, hyphens, and periods: the same characters as a valid host name. Internet domain names or registered trademarks are good choices for publisher names, since these provide natural namespace partitioning.
pkg clients combine all specified sources of packages for a given publisher when computing packaging solutions.
Package names are hierarchical with an arbitrary number of components separated by forward slash (/) characters. Package name components must start with a letter or number, and can include underscores (_), hyphens (-), periods (.), and plus signs (+). Package name components are case sensitive.
Leading components of package names can be omitted if the package name that is used is unique. For instance, /driver/network/ethernet/e1000g can be reduced to network/ethernet/e1000g, ethernet/e1000g, or even simply e1000g. FMRIs can also be specified using an asterisk (*) to match any portion of a package name. Thus /driver/*/e1000g and /dri*00g both expand to /driver/network/ethernet/e1000g.
Package names should be chosen to reduce ambiguities as much as possible. Package names form a single namespace across publishers. Packages with the same name and version but different publishers are assumed to be interchangeable in terms of external dependencies and interfaces. See Avoiding Conflicting Package Content for a discussion of package names and dependencies.
When a package name starts with pkg:/, /, pkg://publisher/, or //publisher/, the package name is considered to be complete, or rooted. If the pkg client complains about ambiguous package names, specify more components of the package name or specify the full, rooted name.
If an FMRI contains a publisher name, then the full, rooted package name must be specified.
Scripts should refer to packages by their full, rooted names, although the publisher can be omitted.
The package version has the following four parts:
component_version,release-branch_version:time_stamp
The component version, release, and branch version can be arbitrarily long and must consist of only integers and period characters (.). A sequence of more than one integer cannot begin with a zero (0). See Construct an Appropriate Package Version String for help converting your product version to an IPS package version.
The time stamp has the following parts. The date and time must consist of only integers.
dateTtimeZ
The component version and release are separated by a comma (,). The release and branch version are separated by a hyphen (-). The branch version and time stamp are separated by a colon (:).
The following example package version is described below:
0.5.11,5.11-0.175.3.0.0.19.0:20150329T164922Z
For components tightly bound to the operating system, the component version usually includes the value of uname -r for that version of the operating system. For a component with its own development lifecycle, the component version is a dotted release number, such as 2.4.10.
The release, if present, must follow a comma (,). Oracle Solaris uses this sequence to specify the release of the OS for which the package was compiled.
The branch version, if present, must follow a hyphen (-). The branch version provides vendor-specific information. This sequence can contain a build number or provide some other information. This value can be incremented when the packaging metadata is changed, independently of the component. See Oracle Solaris Package Versioning for a description of how the branch version fields are used in Oracle Solaris.
The time stamp, if present, must follow a colon (:). The time stamp is the time the package was published in ISO-8601 basic format: YYYYMMDDTHHMMSSZ. The time stamp is automatically updated when the package is published.
The package versions are ordered using left-to-right precedence: The number immediately after the @ is the most significant part of the version space. The time stamp is the least significant part of the version space.
The pkg.human-version attribute can be used to provide a human-readable version string. The value of the pkg.human-version attribute can be provided in addition to the package version described above for the package FMRI but cannot replace the package FMRI version. The human-readable version string is used only for display purposes. See Set Actions for more information.
By allowing arbitrary version lengths, IPS can accommodate a variety of different models for supporting software. For example, a package author can use the build or branch versions and assign one portion of the versioning scheme to security updates, another for paid versus unpaid support updates, another for minor bug fixes, or whatever information is needed.
A version can also be the token latest, which specifies the latest version known.
How IPS Is Used To Package the Oracle Solaris OS describes how Oracle Solaris implements versioning.
Actions define the software that comprises a package; they define the data needed to create this software component. Package contents are expressed in a package manifest file as a set of actions.
Package manifests are largely created using programs. Package developers provide necessary information about the object to be installed, and the manifest is completed using package development tools as described in Packaging Software With IPS.
Actions are expressed in the following form in package manifest files:
action_name attribute1=value1 attribute2=value2 ...
In the following example action, dir indicates this action specifies a directory. Attributes in the form name=value describe properties of that directory:
dir path=a/b/c group=sys mode=0755 owner=root
Action metadata is freely extensible. Additional attributes can be added to actions as needed. Attribute names cannot include spaces, quotation marks, or equals signs (=). Attribute values can have all of those, although values with spaces must be enclosed in single or double quotation marks. Single quotation marks need not be escaped inside a string enclosed in double quotation marks, and double quotation marks need not be escaped inside a string enclosed in single quotation marks. A quotation mark can be prefixed with a backslash character (\) to prevent terminating the quoted string. Backslashes can be escaped with backslashes. Custom attribute names should use a unique prefix to prevent accidental namespace overlap. See the discussion of publisher names in Package Publisher.
Actions can have multiple attributes. Some attributes can be named multiple times with different values for a single action. Multiple attributes with the same name are treated as unordered lists.
Actions with many attributes can create long lines in a manifest file. Such lines can be wrapped by terminating each incomplete line with a backslash character. Note that this continuation character must occur between attribute/value pairs. Neither attributes nor their values nor the combination can be split.
Some attributes cause additional operations to be executed outside of the packaging context. See Automating System Change as Part of Package Installation for more information.
Most actions have a key attribute. The key attribute is the attribute that makes this action unique from all other actions in the image. For file system objects, the key attribute is the path for that object.
Actions that are installed to a path must not deliver content to any of the following paths:
/system/volatile
/tmp
/var/pkg
/var/share
/var/tmp
The following sections describe each IPS action type and the attributes that define these actions. The action types are detailed in the pkg(5) man page, and are repeated here for reference. Each section contains an example action as it would appear in a package manifest during package creation. Other attributes might be automatically added to the action during publication.
The file action is by far the most common action. A file action represents an ordinary file. The file action references a payload, and has the following four standard attributes:
The file system path where the file is installed. This is the key attribute of a file action. The value of the path attribute is relative to the root of the image. Do not include the leading /.
The access permissions of the file. The value of the mode attribute is simple permissions in numeric form, not ACLs.
The name of the user that owns the file.
The name of the group that owns the file.
The payload attribute is positional: The payload attribute is the first word after the action name and usually has no attribute name. If in a manifest that has not yet been published, the value of the payload attribute is the full path to the payload file, less the leading slash character (/). If the payload value includes an equal symbol (=), use hash= in front of the payload attribute value. If both positional and hash payload attributes are used in the same action, the values must be identical.
The following example is a file action that you might see output by the pkgsend generate command as shown in Generate a Package Manifest:
file opt/mysoftware path=opt/mysoftware group=bin mode=0644 owner=root
The following example shows how to specify a path that includes an equal symbol:
file hash=opt/my=software path=opt/my=software group=root mode=0644 owner=root
In a published manifest, the value of the payload attribute is a hash of the file contents, which is used by the package system. See the pkgsend(1) man page for more information.
The preserve and overlay attributes affect whether and how a file action is installed.
Specifies when and how files are preserved during package operations.
When a package is initially installed, if a file delivered by the package has a preserve attribute defined with any value except abandon or install-only and file already exists in the image, the existing file is stored in /var/pkg/lost+found and the packaged file is installed.
When a package is initially installed, if a file delivered by the package has a preserve attribute defined and the file does not already exist in the image, whether that file is installed depends on the value of the preserve attribute:
If the value of preserve is abandon or legacy, the packaged file is not installed.
If the value of preserve is not abandon or legacy, the packaged file is installed.
When a package is downgraded, if a file delivered by the downgraded version of the package has a preserve attribute defined with any value except abandon or install-only and all of the following conditions are true, the file that currently exists in the image is renamed with the extension .update, and the file from the downgraded package is installed.
The file exists in the image.
The content of the file delivered by the downgraded version of the package is different from the content of the file delivered by the currently installed version of the package.
The content of the file delivered by the downgraded version of the package is different from the content of the file that exists in the image.
If any of the above conditions is not true, the file is treated the same as if the package is being upgraded, rather than downgraded.
When a package is upgraded, if a file action delivered by the upgraded version of the package has a preserve attribute defined with any value and the file action is the same as the file action delivered by the currently installed version of the package, the file is not installed, and the file that exists in the image is not modified. Any modifications made since the previous version was installed are preserved.
When a package is upgraded, if a file action delivered by the upgraded version of the package has a preserve attribute defined and the file action is new or is different from the file action delivered by the currently installed version of the package, the upgrade is done in the following way:
If the file delivered by the upgraded version of the package has a preserve value of abandon or install-only in the upgraded package, the new file is not installed and the existing file is not modified.
If the file does not exist in the image, the new file is installed.
If the file delivered by the upgraded version of the package exists in the image, did not exist in the currently installed version of the package, and was not renamed or moved by using the original_name attribute, then the existing file is stored in /var/pkg/lost+found and the file delivered by the upgraded version of the package is installed. See the original_name attribute description below.
If the file delivered by the upgraded version of the package exists in the image and has different content from the file delivered by the currently installed version of the package, the upgrade is done according to the value of the preserve attribute:
If the file delivered by the upgraded version of the package has a preserve value of renameold, the existing file is renamed with the extension .old, and the new file is installed with updated permissions and timestamp (if present). See the timestamp attribute description below.
If the file delivered by the upgraded version of the package has a preserve value of renamenew, the new file is installed with the extension .new and the existing file is not modified.
If the file delivered by the upgraded version of the package has a preserve value of true, the new file is not installed, but the permissions and timestamp (if present) are reset on the existing file.
If the file delivered by the upgraded version of the package exists in the image, has the same content as the file delivered by the currently installed version of the package, and has a preserve value of either renameold or renamenew, the existing file is replaced by the file delivered by the upgraded version of the package, including replacing permissions and timestamp (if present).
If the file delivered by the upgraded version of the package exists in the image, has a preserve value of legacy in the upgraded package, and has a different preserve value in the currently installed version of the package, the existing file is renamed with the extension .legacy, and the new file is installed with updated permissions and timestamp (if present).
If the file delivered by the upgraded version of the package exists in the image and has a preserve value of legacy in both the upgraded package and the currently installed version of the package, the permissions and timestamp (if present) are reset on the existing file.
When a package is uninstalled, if a file action delivered by the currently installed version of the package has a preserve value of abandon or install-only and the file exists in the image, the file is not removed.
Specifies whether the action allows other packages to deliver a file at the same location or whether it delivers a file intended to overlay another file. This functionality is intended for use with configuration files that do not participate in any self-assembly and that can be safely overwritten.
If overlay is not specified, multiple packages cannot deliver files to the same location.
The overlay attribute can have one of the following values:
One other package is allowed to deliver a file to the same location. This value has no effect unless the preserve attribute is also set.
The file delivered by the action overwrites any other action that has specified allow.
Changes to the installed file are preserved based on the value of the preserve attribute of the overlaying file. On removal, the contents of the file are preserved if the action being overlaid is still installed, regardless of whether the preserve attribute was specified. Only one action can overlay another action, and the mode, owner, and group attributes must match.
The following attributes are recognized for ELF files:
The architecture of the ELF file. This value is the output of uname -p on the architecture for which the file is built.
This value is 32 or 64.
This value is the hash of the ELF sections in the file that are mapped into memory when the binary is loaded. These are the only sections necessary to consider when determining whether the executable behavior of two binaries will differ.
The following additional attributes are recognized for file actions:
This attribute is used to handle editable files moving from package to package, from place to place, or both. The value of this attribute is the name of the originating package, followed by a colon, followed by the original path to the file. Any file being deleted is recorded either with its package and path, or with the value of the original_name attribute if specified. Any editable file being installed that has the original_name attribute set uses the file of that name if it is deleted as part of the same packaging operation.
Once this attribute is set, do not change its value, even if the package or file are repeatedly renamed. Keeping the same value permits upgrade to occur from all previous versions.
This attribute is used to indicate that this file contains release note text. The value of this attribute is a package FMRI. If the FMRI specifies a package name that is present in the original image and a version that is newer than the version of the package in the original image, this file will be part of the release notes. A special FMRI of feature/pkg/self refers to the containing package. If the version of feature/pkg/self is 0, this file will only be part of the release notes on initial installation.
This attribute is used to tag editable files that should be reverted as a set. The value of the revert-tag attribute is a tagname. Multiple revert-tag attributes can be specified for a single file action. The file reverts to its manifest-defined state when pkg revert is invoked with any of those tags specified. See Reverting Tagged Files and Directories in Adding and Updating Software in Oracle Solaris 11.3 and the pkg(1) man page for information about the pkg revert command. Certain tags cause files to revert during system migration and system cloning. See Packaging for System Migration and System Cloning and Oracle Solaris Revert Tags for descriptions of these revert tags.
The revert-tag attribute can also be specified at the directory level. See “Directory Actions” below.
This attribute is used to specify any system attributes that should be set for this file. The value of the sysattr attribute can be a comma-separated list of verbose system attributes or a string sequence of compact system attribute options, as shown in the following examples. Supported system attributes are explained in the chmod(1) man page. System attributes specified in the manifest are set additionally to system attributes that might have been set by other subsystems of the operating system.
file path=opt/secret_file sysattr=hidden,sensitive file path=opt/secret_file sysattr=HT
This attribute is used to set the access and modification time on the file. The timestamp attribute value must be expressed in UTC in ISO-8601 format, omitting the colons and hyphens.
The timestamp attribute is essential when packaging .pyc or .pyo files for Python. The related .py file for the .pyc or .pyo files must be marked with the timestamp embedded within those files, as shown in the following example:
file path=usr/lib/python2.6/vendor-packages/pkg/__init__.pyc ...
file path=usr/lib/python2.6/vendor-packages/pkg/__init__.py \
timestamp=20150331T111615Z ...
The following attributes for file actions are automatically generated by the system and should not be specified by package developers: hash, chash, pkg.size, pkg.csize, and pkg.content-hash.
An example file action is:
file path=usr/bin/pkg owner=root group=bin mode=0755
The dir action is like the file action in that it represents a file system object. The dir action represents a directory instead of an ordinary file. The dir action has the same path, mode, owner, and group attributes that the file action has, and path is the key attribute. The dir action also accepts the revert-tag attribute, but the value of the attribute is different for file and dir actions.
Directories are reference counted in IPS. When the last package that either explicitly or implicitly references a directory no longer does so, that directory is removed. If that directory contains unpackaged file system objects, those items are moved into $IMAGE_META/lost+found. The value of $IMAGE_META is typically /var/pkg.
This attribute is used to identify unpackaged files that should be removed as a set. See “File Actions” above for a description of how to specify this attribute for file actions. For directories, the value of the revert-tag attribute is tagname=pattern. Multiple revert-tag attributes can be specified for a single dir action. When pkg revert is invoked with a matching tagname, any unpackaged files or directories under this dir directory that match pattern (using shell globbing characters) are removed. See Reverting Tagged Files and Directories in Adding and Updating Software in Oracle Solaris 11.3 and the pkg(1) man page for information about the pkg revert command.
This attribute can be used to move unpackaged contents into a new directory. The value of this attribute is the name of a directory of salvaged items. A directory with a salvage-from attribute inherits on creation any contents of the directory named in the value of the salvage-from attribute.
During installation, pkg checks that all instances of a given directory action on the system have the same owner, group, and mode attribute values. The dir action is not installed if conflicting values are found on the system or in other packages to be installed in the same operation.
An example of a dir action is:
dir path=usr/share/lib owner=root group=sys mode=0755
The link action represents a symbolic link. The link action has the following standard attributes:
The file system path where the symbolic link is installed. This is the key attribute for a link action.
The target of the symbolic link. The file system object to which the link resolves.
The link action also takes the following attributes that allow for multiple versions or implementations of a given piece of software to be installed on the system at the same time: mediator, mediator-version, mediator-implementation, and mediator-priority. Such links are mediated, and allow administrators to easily toggle which links point to which version or implementation as desired. These mediated link attributes are discussed in detail in Delivering Multiple Implementations of an Application. Mediations are also discussed in Specifying a Default Application Implementation in Adding and Updating Software in Oracle Solaris 11.3.
An example of a link action is:
link path=usr/lib/libpython2.6.so target=libpython2.6.so.1.0
The hardlink action represents a hard link. It has the same path and target attributes as the link action, and path is also its key attribute.
An example of a hardlink action is:
hardlink path=opt/myapplication/hardlink target=foo
The set action represents a package-level attribute, or metadata, such as the package description.
The following attributes are recognized:
The name of the attribute.
The value given to the attribute.
The set action can deliver any metadata the package author chooses. The following attribute names have specific meaning to the packaging system:
One or more tokens that a pkg client can use to classify the package. The value should have a scheme (such as org.opensolaris.category.2008 or org.acm.class.1998) and the actual classification (such as Applications/Games), separated by a colon (:). A set of info.classification values is provided in Classifying Packages.
A detailed description of the contents and functionality of the package, typically a paragraph or so in length. This value should describe why someone might want to install this package.
The name and version of the containing package. See Package Version.
The version scheme used by IPS is strict. See Package Version. A more flexible version can be provided as the value of the pkg.human-version attribute. The value is displayed by IPS tools such as pkg info, pkg contents, and pkg search. The pkg.human-version value is not used as a basis for version comparison and cannot be used in place of the pkg.fmri version.
When true, the package is marked obsolete. An obsolete package can have no actions other than more set actions, and must not be marked renamed. Package obsoletion is covered in Obsoleting Packages.
When true, the package has been renamed. The package must include one or more depend actions as well, which point to the package versions to which this package has been renamed. A package cannot be marked both renamed and obsolete, but otherwise can have any number of set actions. Package renaming is covered in Renaming, Merging, and Splitting Packages.
A brief synopsis of the description. This value is shown at the end of each line of pkg list -s output, as well as in one line of the output of pkg info. This value should be no longer than 60 characters. This value should describe what the package is, and should not repeat the name or version of the package.
Some additional informational attributes, as well as some used by Oracle Solaris are described in How IPS Is Used To Package the Oracle Solaris OS.
An example of a set action is:
set name=pkg.summary value="Image Packaging System"
The driver action represents a device driver. The driver action does not reference a payload. The driver files themselves must be installed as file actions. The following attributes are recognized. See the add_drv(1M) man page for more information about these attribute values.
The name of the driver. This is usually, but not always, the file name of the driver binary. This is the key attribute of the driver action.
An alias for the driver. A given driver can have more than one alias attribute. No special quoting rules are necessary.
A driver class. A given driver can have more than one class attribute.
The file system permissions for the device nodes of the driver.
The file system permissions for the minor nodes of the clone driver for this driver.
Additional security policy for the device. A given driver can have more than one policy attribute, but no minor device specification can be present in more than one attribute.
Privileges used by the driver. A given driver can have more than one privs attribute.
An entry in /etc/devlink.tab. The value is the exact line to go into the file, with tabs denoted by \t. See the devlinks(1M) man page for more information. A given driver can have more than one devlink attribute.
An example of a driver action is:
driver name=vgatext \
alias=pciclass,000100 \
alias=pciclass,030000 \
alias=pciclass,030001 \
alias=pnpPNP,900 variant.arch=i386 variant.opensolaris.zone=global
The depend action represents an inter-package dependency. A package can depend on another package because the first package requires functionality in the second package for the functionality in the first package to work or to install. Dependencies can be optional. If a dependency is not satisfied at the time of installation, the packaging system attempts to install or update the dependent package to a sufficiently new version, subject to other constraints. Dependencies are covered in more detail in Specifying Package Dependencies.
The following attributes are recognized:
The FMRI representing the target of the dependency. This is the key attribute of the depend action. The FMRI value must not include the publisher. The package name is assumed to be rooted, even if it does not begin with a forward slash (/). Dependencies of type require-any can have multiple fmri attributes. A version is optional on the fmri value, though for some types of dependencies, an FMRI with no version has no meaning.
The FMRI value cannot use asterisks (*), and cannot use the latest token for a version.
The type of the dependency.
The target package is required and must have a version equal to or greater than the version specified in the fmri attribute. If the version is not specified, any version satisfies the dependency. A package cannot be installed if any of its require dependencies cannot be satisfied.
The dependency target, if present, must be at the specified version level or greater.
The containing package cannot be installed if the dependency target is present at the specified version level or greater. If no version is specified, the target package cannot be installed concurrently with the package specifying the dependency.
The dependency is optional, but the version of the target package is constrained. See Specifying Package Dependencies for a discussion of constraints and freezing.
Any one of multiple target packages as specified by multiple fmri attributes can satisfy the dependency, following the same rules as the require dependency type.
The dependency target is required only if the package defined by the predicate attribute is present on the system.
Prior to installation of this package, the dependency target must, if present, be at the specified value or greater on the image to be modified. If the value of the root-image attribute is true, the target must be present on the image rooted at / in order to install this package. If the value of the root-image attribute is true and the value of the fmri attribute starts with pkg:/feature/firmware/, the remainder of the fmri value is treated as a command in /usr/lib/fwenum that evaluates the firmware dependency.
The dependency target is required unless the package is on the image avoid list. Note that obsolete packages silently satisfy the group dependency. See the avoid subcommand in the pkg(1) man page for information about the image avoid list.
Any one of multiple target packages as specified by multiple fmri attributes can satisfy the dependency. The same rules apply to a group-any dependency that apply to a group dependency with the exception that non-obsolete package stems are preferred over obsolete package stems.
The dependency is ignored if the image is not a child image, such as a zone. If the image is a child image, then the dependency target must be present in the parent image. The version matching for a parent dependency is the same as that used for incorporate dependencies.
The FMRI that represents the predicate for conditional dependencies.
Has an effect only for origin dependencies as mentioned above.
An example of a depend action is:
depend fmri=crypto/ca-certificates type=require
The license action represents a license or other informational file associated with the package contents. A package can deliver licenses, disclaimers, or other guidance to the package installer through the license action.
The payload of the license action is delivered into the image metadata directory related to the package, and should only contain human-readable text data. The license action payload should not contain HTML or any other form of markup. Through attributes, license actions can indicate to pkg clients that the related payload must be displayed or accepted. The method of display or acceptance is at the discretion of pkg clients.
The following attributes are recognized:
Provides a meaningful description for the license to assist users in determining the contents without reading the license text itself. This is the key attribute of the license action.
Some example values include:
ABC Co. Copyright Notice
ABC Co. Custom License
Common Development and Distribution License 1.0 (CDDL)
GNU General Public License 2.0 (GPL)
GNU General Public License 2.0 (GPL) Only
MIT License
Mozilla Public License 1.1 (MPL)
Simplified BSD License
Wherever possible, including the version of the license in the description is recommended as shown above. The license value must be unique within a package.
When true, this license must be accepted by a user before the related package can be installed or updated. Omission of this attribute is equivalent to false. The method of acceptance (interactive or configuration-based, for example) is at the discretion of pkg clients. For package updates, this attribute is ignored if the license action or payload has not changed.
When true, the payload of the license action must be displayed by pkg clients during packaging operations. Omission of this attribute is equivalent to false. This attribute should not be used for copyright notices. This attribute should only be used for licenses or other material that must be displayed during operations. The method of display is at the discretion of pkg clients. For package updates, this attribute is ignored if the license action or payload has not changed.
An example of a license action is:
license license="Apache v2.0"
The legacy action represents package data used by the legacy SVR4 packaging system. The attributes associated with the legacy action are added into the databases of the legacy SVR4 packaging system so that the tools querying those databases can operate as if the legacy package were actually installed. In particular, specifying the legacy action should cause the package named by the pkg attribute to satisfy SVR4 dependencies.
The following attributes are recognized. See the pkginfo(4) man page for description of the associated parameters.
The value for the CATEGORY parameter. The default value is system.
The value for the DESC parameter.
The value for the HOTLINE parameter.
The value for the NAME parameter. The default value is none provided.
The abbreviation for the package being installed. The default value is the name from the FMRI of the package. This is the key attribute of the legacy action.
The value for the VENDOR parameter.
The value for the VERSION parameter. The default value is the version from the FMRI of the package.
An example of a legacy action is:
legacy pkg=SUNWcsu arch=i386 category=system \
desc="core software for a specific instruction-set architecture" \
hotline="Please contact your local service provider" \
name="Core Solaris, (Usr)" vendor="Oracle Corporation" \
version=11.11,REV=2009.11.11 variant.arch=i386
Signature actions are used as part of the support for package signing in IPS. Signature actions are covered in detail in Signing IPS Packages.
The user action defines a UNIX user as specified in the /etc/passwd, /etc/shadow, /etc/group, and /etc/ftpd/ftpusers files. Information from user actions is added to the appropriate files.
The user action is intended to define a user for a daemon or other software to use. Do not use the user action to define administrative or interactive accounts.
The following attributes are recognized:
The unique name of the user.
The encrypted password of the user. The default value is *LK*.
The unique numeric ID of the user. The default value is the first free value under 100.
The name of the user's primary group. This name must be found in /etc/group.
The real name of the user, as represented in the GECOS field in /etc/passwd. The default value is the value of the username attribute.
The user's home directory. This directory must be in the system image directories and not under another mount point such as /home. The default value is /.
The user's default shell. The default value is empty.
Secondary groups to which the user belongs. See the group(4) man page.
Can be set to true or false. The default value of true indicates that the user is permitted to login via FTP. See the ftpusers(4) man page.
The number of days between January 1, 1970, and the date that the password was last modified. The default value is empty.
The minimum number of days required between password changes. This field must be set to 0 or above to enable password aging. The default value is empty.
The maximum number of days the password is valid. The default value is empty. See the shadow(4) man page.
The number of days before password expires that the user is warned.
The number of days of inactivity allowed for the user. This is counted on a per-system basis. The information about the last login is taken from the lastlog file of the system.
An absolute date expressed as the number of days since the UNIX Epoch (January 1, 1970). When this number is reached, the login can no longer be used. For example, an expire value of 13514 specifies a login expiration of January 1, 2007.
Set to empty.
A example of a user action is:
user ftpuser=false gcos-field="AI User" group=aiuser uid=61 username=aiuser
The group action defines a UNIX group as specified in the group(4) file. No support is provided for group passwords. Groups defined with the group action initially have no user list. Users can be added with the user action.
The following attributes are recognized:
The value for the name of the group.
The unique numeric ID of the group. The default value is the first free group under 100.
An example of a group action is:
group gid=61 groupname=aiuser
A software repository contains packages for one or more publishers. Repositories can be configured for access in a variety of different ways: HTTP, HTTPS, file (on local storage or via NFS or SMB), and as a self-contained package archive file, usually with the .p5p extension.
Package archives allow for convenient distribution of IPS packages. See Deliver as a Package Archive File for more information.
A repository accessed via HTTP or HTTPS is managed by a pkg/server SMF service and pkg.depotd process or possibly by a pkg/depot SMF service. The pkg/depot service is delivered by the package/pkg/depot package. For file repositories, the repository software runs as part of the accessing pkg client.
See Publish the Package and Deliver the Package for examples. See Copying and Creating Package Repositories in Oracle Solaris 11.3 for more information about creating, accessing, updating, and configuring IPS package repositories.