On Mon, Mar 31, 2008 at 4:12 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote:
>  | PSARC/2008/190
>  | pkg(5): image packaging system

<snip>

>  | 2.2.  Domain-name-based escape
>  |
>  |     At any point in the category hierarchy, a safe namespace can be

As others have mentioned, can you clarify what "safe namespace" means
in this context?

>  |     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.

As Peter mentioned, I would prefer to see one valid naming scheme
here. I think when you are trying to explain these to end users, or
document them, it would be far less confusing to have one form.

In addition, it would make it easier to create "home-grown" tools that
can parse and/or analyse these.

I am also a little concerned about what mechanisms might be in place
to restrict or limit publishing rights.

For example, I would expect that "authorities" would have an
associated public key of some sort, that would prevent others without
that same key from publishing under that authority's identity.

>  | 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.
>  |     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

What is the motivation behind using categories to establish namespace?

I would expect packages to often be present in multiple categories,
and for those categories to change frequently enough that it shouldn't
be used for the namespace.

Is there a concern that having a flat namespace under a particular
authority would not be sufficiently flexible in cases where there
might be two similarly named packages with providing disparate
functionality?

>  | 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.
>  |

While I'm not keen on "custom" categories being used to establish
namespace, I do like the idea of top-level "special" categories that
clearly establish different types of packages.

Overall, my thoughts tend to align with those of Mike and Peter. I'd
feel better about this if I understood the motivation behind some of
the namespace decisions.

Cheers,
-- 
Shawn Walker

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to