I've been needing to trim down the lists I am on and may have missed
some important decisions around sections 1 - 2.2. If such discussions
exist, please let me know and I will try to make sense of them.
On Mon, Mar 31, 2008 at 4:12 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote:
> | PSARC/2008/190
> | pkg(5): image packaging system
>
> | PACKAGES AND GROUPS
>
> | 1. Definitions
>
> | 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]
>
> | The authority is generally expected to be a forward or reverse
> | domain name identifying the publisher from which a package can be
> | retrieved. Authorities which cannot be determined to be a domain
> | name are legitimate, but optional functionality, like automatic
> | server discovery for a particular authority, may fail to work.
> | In the examples that follow, we use "opensolaris.org" as a generic
> | authority.
What domain does pkg://us.com/[EMAIL PROTECTED] belong to? What happens when
Sun publishes packages as pkg://sun.com/ and IANA adds .sun as a TLD?
Did I miss some sort of background as to why both forms are considered
equally valid?
Is it intended that the domain name given corresponds to the actual
hostname that pkg(1M) would connect to or is there configuration
saying that for opensolaris.org, really use pkg.opensolaris.org (or
better yet mirror.mycompany.com)?
> | 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.
Does it also address the need to mirror package repositories, possibly
behind firewalls where most of .com is not found in DNS and proxy
servers may not be available?
> | 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.)
Are there any references to this? My snv_69 system has no services
with a comma in the fmri and the smf(5) man page does not mention the
use of a comma or "namespace escapes".
> | 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.
Does "..." mean "..." or something else (e.g. "vendor")?
Why would example.com choose one name over another? In particular I
don't understand why someone would choose to use a comma here.
> | 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.
> |
> | The top-level "vendor" category is reserved for use by organizations
> | providing additional. The leading subcategory must be a domain.
The first sentence seems to be missing something:
providing additional ____.
> | 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
Suppose apache.org published the exact same ant release as:
pkg://opensolaris.org/vendor/apache.org/ant
pkg://blastwave.org/vendor/apache.org/ant
pkg://apache.org/devtools/ant
Is there any way to for a consumer system to understand that they are
equivalent for the purpose of dependency mapping?
> | 2.3. Additional reserved namespace
> |
> | The top-level "cluster", "feature", "group", "metacluster", and
> | "service" categories are all reserved for future use.
> |
> | Inception note: some or all of these reservations may be eliminated
> | or reduced when the single namespace convention reaches its final
> | form.
> |
> | 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
The technology junkie may like this approach more because they
understand the differences from an old X11 application and the
equivalents in KDE and/or GNOME.
Most people I run into in the business world want apps that work.
Aside from purchasing issues, they don't care too much about what
vendor produced them, which toolkits they use, etc. This type of
person has probably missed out on the KDE vs. GNOME wars and has no
idea which GUI toolkit Firefox uses. I bet that most of these type of
people don't think to look for a GUI tool under an X11 classification.
In other words, this was a fine way of classifying tools when the
typical UNIX user was a technology junkie, but now they tend to be
people that are trying to run a business or watch April Fools pranks
on youtube.
> | 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.
> |
> | An appealing variation of the second form is to rotate all of the
> | non-"application" packages under a "system" mega-category, such that
> | all of the leaf packages (with the possible exception of device
> | drivers) are exposed at the category level. Table 1 shows some
> | example transformations under this scheme.
> |
> | FROM TO
> | application/web/firefox web/firefox
> | application/compiler/gcc4 compiler/gcc4
> | library/c system/library/c
> | kernel/generic system/kernel/generic
> |
> | Table 1: Rotating non-application categories under system.
I like this approach. In a user-centric view, people are much more
likely to see the bells and whistles than the guts of the system. I
think the list in the "From" column represents the system-centric
view. In the system-centric view a UNIX installation as a bunch of
things that make the system run and maybe a pesky application or two.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
