Quick, fever-ridden thoughts.
> 1. Definitions
>
> | Both packages and actions within a package can carry metadata, which
> | we informally refer to as attributes and tags.
We might want to make it clear that, at least informally, we refer to
metadata on packages *and* actions as both attributes and tags. Certainly
the code makes use of the "attrs" member of an action, and I know we talk
about "tagging" packages with some frequency. When I talk about a piece of
package-level metadata, I tend to say "package attribute".
We can try to formalize it for the ARC documentation so that readers aren't
confused by inconsistency, but we shouldn't be shy about explaining that we
are inconsistent.
> | 2. Attribute and tag syntax and namespace
>
> | 2.1. Syntax
>
> | The syntax for attributes and tags is similar to that used for
> | pkg(5) and smf(5) FMRIs.
>
> | [org_prefix,][name][:locale]
> |
> | The organizational prefix is a forward-ordered or reverse-ordered
> | domain name, followed by a common.
We should pick either forward or reverse, rather than leaving it open.
And I believe that the prefix is followed by a comma.
> | 2.3. Attributes and tags common to all packages
> |
> | The "pkg" attribute is to be used for attributes common to all
> | packages, regardless of which particular OS platforms that a specific
> | package may target.
> |
> | 2.3.1. Common attributes
> |
> | pkg.name
> | A short, descriptive name for the package. In accordance with
> | 2.1 above, pkg.name:fr would be the descriptive name in French.
> | Exact numerical version strings are discouraged in the
> | descriptive name.
> |
> | Example: "Apache HTTPD Web Server 2.x"
I know I've been confused time and again by the use of "NAME" in svr4
packages not to mean the handle you use to refer to it, say, on the
commandline.
Perhaps "summary" would be better?
Would it be useful to say more explicitly which, if any, of these
attributes should ever be Committed interfaces? Or their contents? I
wouldn't want people trying to put structured text into pkg.description,
say.
> | pkg.detailed_url
> | One or more URLs to pages or sites with further information about
> | the package.
It might be worth mentioning that you can set an attribute multiple times
in a package to get a list of values associated with that attribute. I
don't think this actually works right now, but like for action attributes,
I think it probably should. This would pre-empt questions about comma vs
space separation.
> | 2.3.2. Common tags
> |
> | XXX pkg.platform
What's XXX about this, other than needing a description?
> | XXX ISA (particularly need to know i386 on i86pc vs amd64 on i86pc)
This is elfbits currently, right?
> | pkg.compatibility
> (for shipping non-bleeding edge .so.x.y.z copies, perhaps)
This might take an XXX.
> | 2.4. Attributes common to all packages for an OS platform
>
> | Each OS platform is expected to define a string representing that
> | platform. For example, the OpenSolaris platform is represented by
> | the string "opensolaris".
>
> | XXX Or "osol"?
Why doesn't this fall under the syntax in 2.1? That is, why isn't this
"org.opensolaris,"?
> | 2.4.1. OpenSolaris attributes
>
> | opensolaris.arc_url
> | One or more URLs associated with the ARC case or cases
> | associated with the component(s) delivered by the package.
I'm happy to try this out, but I think this would be a pain to figure out
and maintain, particularly when packages split.
> | opensolaris.maintainer
> | A human readable string describing the entity providing the
> | package. For an individual, this string is expected to be their
> | name, or name and email.
Perhaps more tightly defined as a name, or an email address in 822-normal
form ("First Last <[EMAIL PROTECTED]>")?
> | opensolaris.upstream
> | A human readable string describing the entity that creates the
> | software. For an individual, this string is expected to be
> | their name, or name and email.
Author, maybe, rather than upstream? Originator?
> | 3.3. Attributes best avoided
>
> built-on release
This all needs some cleanup, given that built-on already exists in the fmri
definitions. Though we're never using it, and the code is cluttered with
hardcoded instances of "5.11" because *something* there is required in
order to construct an fmri. Unlike any of the other version fields.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
