1923N/A.. The contents of this file are subject to the terms of the
1923N/A Common Development and Distribution License (the "License").
1923N/A You may not use this file except in compliance with the License.
1923N/A See the License for the specific language governing permissions
1923N/A and limitations under the License.
1923N/A.. When distributing Covered Code, include this CDDL HEADER in each
1923N/A If applicable, add the following below this CDDL HEADER, with the
1923N/A fields enclosed by brackets "[]" replaced with your own identifying
1923N/A information: Portions Copyright [yyyy] [name of copyright owner]
1923N/A.. Copyright (c) 2010, Oracle
and/or its affiliates. All rights reserved.
1923N/ATo be consistent with the system, following the introduction of the
1923N/Afault management architecture, each package is named by an FMRI in the
1923N/A``pkg:`` scheme. That is, we have::
2787N/AThe publisher is generally expected to be a forward or reverse domain
1923N/Aname identifying the publisher from which a package can be retrieved.
2787N/APublishers which cannot be determined to be a domain name are
1923N/Alegitimate, but optional functionality, like automatic server discovery
2787N/Afor a particular publisher, may fail to work. In the examples that
1923N/AAlthough RFC 2396 usage would suggest using the "authority" term, we
1923N/Ainstead call it the publisher name, as the role of this section of the
1923N/AFMRI is to identify the source for the package, which we consider a
1923N/Apublication of one or more software components.
1923N/AThe pkg_name, like service names, can be split into a category,
1923N/Asubcategories, and a basename. This namespace might be populated
1923N/Awith "manifest" and other metadata endpoints, as well as the SHA-1
1923N/Anames of the package's included files. (Although the direct access
1923N/Ato properties of the ``svc`` FMRI scheme has been rarely used.)
1923N/AA "group package" is a package that depends upon (minimum versions
1923N/Aof) other packages, as well as optionally delivering files or other
1923N/Aactions. An "incorporating package" is a group package that places
1923N/Aforward constraints upon the versions of the packages it depends upon,
1923N/Awhich restricts the interval of valid package versions to one the author
1923N/Aof the incorporation believes functional.
2787N/ASingle namespace, separate publishers
1923N/A``````````````````````````````````````
1923N/AThe primary design point of the package namespace is to allow
1923N/Amultiple package producers to co-exist in a single namespace, so
1923N/Athat images can switch between equivalent components from different
1923N/AAt any point in the category hierarchy, a safe namespace can be created
1923N/Aby using the forward or reverse domain name, either as a subcategory or
1923N/Aas a comma-led prefix to a subcategory or package base name. (This
1923N/Ascheme is similar to FMRI namespace escapes in smf(5), although we are
1923N/Aeliminating use of stock symbol prefixes.) Generally, safe namespaces
1923N/Aare only needed when the components delivered by a package need to be
1923N/Adistinguished from those delivered by a package in the single namespace;
1923N/Areasons for distinguishing the components might include construction of
1923N/Aa collection of components, insulated from changes in the wider system,
1923N/Apackage without reference to a larger namespace convention it can
1923N/Ause any of the following examples::
1923N/AThe top-level "site" category is reserved for use by the entity that
1923N/Aadministrates the server. Neither the organizations producing the
1923N/Aoperating system nor those providing additional software components may
1923N/AThe top-level "vendor" category is reserved for use by organizations
1923N/Aproviding additional. The leading subcategory must be a domain. That
1923N/Avendor category, it would use a package name like::
1923N/AUse of the "vendor" category, and the vendor-escaped packages below, is
1923N/Alikely only to be of interest to organizations that redistribute
1923N/Asoftware from multiple source vendors.
1923N/AAdditional reserved namespace
1923N/A`````````````````````````````
1923N/A Some or all of these reservations may be eliminated or reduced when
1923N/A the single namespace convention reaches its final form.
1923N/AThe top-level "cluster", "feature", "group", and "metacluster"
1923N/Acategories are all reserved for future use.
1923N/ASingle namespace conventions
1923N/A````````````````````````````
1923N/APackaging systems and distributions appear to have explicit
1923N/Acategories, subcategories, and potentially larger groups; some
1923N/Adistributions have explicit fields for these values, others use
1923N/Atagging or multi-valued fields, which allows them to classify
1923N/Acertain packages multiply. For the FMRI namespace case, the system
1923N/Ais similar to a packaging system with multiple, single-valued,
1923N/AThere appear to be two standard approaches to categorizing packages:
293N/A 1. By what primary class of thing a package delivers.
293N/A 2. By what area of functionality a package's contents address.
1923N/AIn the first approach, we get strict top-level categories like
1923N/A"application", "driver", "library", and "system" or "kernel", as
1923N/Awell as potentially overlapping categories like "utility" and
1923N/A"tool". Use of the leading subcategory is limited, and generally
1923N/Agiven to the subsystem involved. A relatively detailed worked
1923N/Aexample of the X11 subsystem under this scheme is given in
1923N/AXXX This reference is now wrong.
1923N/AIn the second, we would also see categories like these, but leading
1923N/Asubcategory is much more likely to classify according to
1923N/Anetwork packaging systems appear to classify in this fashion.
1923N/AAn appealing variation of the second form is to rotate all of the
1923N/Anon-"application" packages under a "system" mega-category, such that
1923N/Aall of the leaf packages (with the possible exception of device
1923N/Adrivers) are exposed at the category level. Table 1 shows some
1923N/Aexample transformations under this scheme.
1923N/A.. table:: Rotating non-application categories under system.
1923N/A ========================= ====================
1923N/A ========================= ====================
1923N/A ========================= ====================