Every IPS package is represented by a fault management resource identifier (FMRI) that consists of a publisher, a name, and a version, with the scheme pkg. In the following example package FMRI, solaris is the publisher, system/library is the package name, and 0.5.11,5.11-0.175.0.0.0.2.1:20111019T082311Z is the version:
pkg://solaris/system/library@0.5.11,5.11-0.175.1.0.0.2.1:20120919T082311Z
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.
Package 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.
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.
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. When no components are omitted from the package name, the package name is considered complete, or rooted. If the packaging client complains about ambiguous package names, specify more components of the package name or specify the full, rooted name. Package names should be chosen to reduce possible ambiguities as much as possible.
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.
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.
A package version consists of four sequences of positive integers, separated by punctuation. The elements in the first three sequences are separated by period characters (.), and the sequences are arbitrarily long. Leading zeros in version elements are not allowed, to enable unambiguous sorting by package version. For example, 01.1 and 1.01 are invalid version elements.
In the following example package version, the first sequence is 0.5.11, the second sequence is 5.11, the third sequence is 0.175.1.0.0.2.1, and the fourth sequence is 20120919T082311Z.
0.5.11,5.11-0.175.1.0.0.2.1:20120919T082311Z
The first sequence is the component version. For components that are developed as part of Oracle Solaris, this sequence represents the point in the release when this package last changed. For a component with its own development life cycle, this sequence is the dotted release number, such as 2.4.10.
The second sequence is the build version. This sequence, if present, must follow a comma. Oracle Solaris uses this sequence to denote the release of the OS for which the package was compiled.
The third sequence is the branch version, providing vendor-specific information. This sequence, if present, must follow a hyphen. 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 fourth sequence is a time stamp. This sequence, if present, must follow a colon. This sequence represents the date and time the package was published in the GMT time zone. This sequence 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 only used 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.
Appendix B, How IPS Is Used To Package the Oracle Solaris OS describes how Oracle Solaris implements versioning.