On Mon, Mar 31, 2008 at 10:12 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > | To be consistent with the system, following the introduction of the > | fault management architecture, each package is named by an FMRI in > | the "pkg:" scheme. That is, we have > > | pkg://authority/[EMAIL PROTECTED]
Looking at your examples later, is the @version part optional? > | The authority is generally expected to be a forward or reverse > | domain name identifying the publisher from which a package can be > | retrieved. It should be one or the other. I'm used to java, so reverse looks more familiar. (Although being from the UK and going back a bit I'm also used to having domain names backward.) > | A "group package" is a package that depends upon (minimum versions > | of) other packages, as well as optionally delivering files or other > | actions. An "incorporation" is a group package that places forward > | constraints upon the versions of the packages it depends upon, which > | restricts the interval of valid package versions to one the author > | of the incorporation believes functional. In what way are group packages and incorporations different from normal packages? I would expect all packages to have dependencies, and to have the ability to limit the versions of their dependencies. > | 2. Namespace > > | 2.1. Single namespace, separate authorities > > | The primary design point of the package namespace is to allow > | multiple package producers to co-exist in a single namespace, so > | that images can switch between equivalent components from different > | producers. How does the namespace help? Are you saying that you expect any two packages with the same unqualified name to be interchangeable? > | 2.2. Domain-name-based escape > | > | At any point in the category hierarchy, a safe namespace can be > | created by using the forward or reverse domain name, either as a > | subcategory or as a comma-led prefix to a subcategory or package > | base name. (This scheme is similar to FMRI namespace escapes in > | smf(5), although we are eliminating use of stock symbol prefixes.) > | > | For instance, when example.com wishes to publish the "whiskers" > | package without reference to a larger namespace convention it can > | use any of the following examples > | > | pkg://opensolaris.org/.../example.com/whiskers > | pkg://opensolaris.org/.../com.example/whiskers > | > | pkg://opensolaris.org/.../example.com,whiskers > | pkg://opensolaris.org/.../com.example,whiskers > | > | pkg://opensolaris.org/.../example.com,software/whiskers > | pkg://opensolaris.org/.../com.example,software/whiskers > | > | and so forth. Gosh. That's confusing. For one thing, I would expect that there would be a single preferred form (and hopefully only a single valid form). For another, I would have expected the authority to be example.com, so that we would end up with pkg://example.com/whiskers and finally, I wouldn't have expected example.com to be able to publish anything under pkg://opensolaris.org - only opensolaris.org can publish (or, in this case, republish) items under its authority. > | 2.2. Locally reserved namespace > | > | The top-level "site" category is reserved for use by the entity that > | administrates the server. Neither the organizations producing the > | operating system nor those providing additional software components > | may use the site category. What sort of things would the site category be used for? > | The top-level "vendor" category is reserved for use by organizations > | providing additional. The leading subcategory must be a domain. > | That is, if example.com wishes to publish the "whiskers" package in > | the vendor category, it would use a package name like > | > | pkg://opensolaris.org/vendor/example.com/whiskers Now I'm even more confused. I can't make sense of what that means. Who's the authority here, and what are they authoritative for? In this scheme, I would expect *all* packages to have a vendor, so that anything coming from opensolaris.org would look like pkg://opensolaris.org/vendor/opensolaris.org/foobar > | 2.4. Single namespace conventions > | > | 2.4.1. Discussion > | > | Packaging systems and distributions appear to have explicit > | categories, subcategories, and potentially larger groups; some > | distributions have explicit fields for these values, others use > | tagging or multi-valued fields, which allows them to classify > | certain packages multiply. For the FMRI namespace case, the system > | is similar to a packaging system with multiple, single-valued, > | category fields. > | > | There appear to be two standard approaches to categorizing packages: > | > | 1. By what primary class of thing a package delivers. > | > | 2. By what area of functionality a package's contents address. > | > | In the first approach, we get strict top-level categories like > | "application", "driver", "library", and "system" or "kernel", as > | well as potentially overlapping categories like "utility" and > | "tool". Use of the leading subcategory is limited, and generally > | given to the subsystem involved. A relatively detailed worked > | example of the X11 subsystem under this scheme is given in > | > | > http://mail.opensolaris.org/pipermail/pkg-discuss/2008-February/001838.html > | > | In the second, we would also see categories like these, but leading > | subcategory is much more likely to classify according to > | functionality, so that we would see "application/mail", > | "application/web", "application/compiler", and so forth. Most > | network packaging systems appear to classify in this fashion. What generates the categories? And how are they discovered? One thing about categorising software is that there are multiple ways of making a hierarchy, each of which is entirely valid. Even from the same supplier, if you change the context (or even the user) the categorisation can change. Does it make sense to use the package namespace to describe categories? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
