Trev
| 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.
Would it be more correct if this read:
The "pkg" prefix is used for attributes and tags which are
generic to the package - ie independent of the OS platform which
the 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"
So I'm assuming that we can handle Unicode characters in this and other fields, then (in storage and in display on the client)?
| pkg.description | A descriptive paragraph for the package. Exact numerical version | strings can be embedded in the paragraph.
It might be handy here to elaborate on "exact numerical version" and why it should not be used in the pkg.name, but is okay to use in the description.
| pkg.detailed_url | One or more URLs to pages or sites with further information about | the package.| | 2.3.2. Common tags
I guess I'm more than a little confused about attributes and tags, since at least two of the tags below seem to me to be better defined as attributes.
| pkg.debug | This file is used when the package is intended to be installed in | a debug configuration. For example, we expect to deliver a debug | version of the kernel, in addition to the standard non-debug | version.
I was trying to think if there was a better tag name than "debug" to represent the intent here. There may be cases where a file is not necessarily for debugging, but may only be for test purposes. Maybe "debug" will suffice? Should this be an attribute rather than a tag?
| XXX pkg.platform| | XXX ISA (particularly need to know i386 on i86pc vs amd64 on i86pc)
These tags seem to contradict the statement in 2.3 about "pkg" being OS platform neutral or am I missing something?
| pkg.compatibility
(for shipping non-bleeding edge .so.x.y.z copies, perhaps)
Isn't this an attribute?
| 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"? | 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 can see that this might be interesting to some classes of users of the packaging system, but for most people it will be meaningless. Is it something you really feel we _should_ carry?
| 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.| | opensolaris.maintainer_url| A URL associated with the entity providing the package.| | 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.| | opensolaris.upstream_url | A URL associated with the entity that creates the | software delivered within the package. | | opensolaris.source_url| A URL to the source code bundle, if appropriate, for the package.| | opensolaris.repository_url| A URL to the source code repository, if appropriate, for the | package.| | opensolaris.repository_changeset| A changeset ID for the version of the source code contained in | opensolaris.repository_url.
Hmm, not sure about this one. Again, I can see that there will be some class of users who are mildly interested in such data, but for the majority, it seems to have no significant value.
| opensolaris.gui.classification | A list of labels classifying the package into the categories | shared among pkg(5) graphical clients.
Are these free-form or a specific, defined set of categories? Is it worth giving examples?
| 2.5. Organization specific attributes| | Organizations wishing to provide a package with additional metadata| or to amend an existing package's metadata (in a repository that | they have control over) must use an organization-specific prefix. | For example, a service organization might introduce | "service.example.com,support_level" or | "com.example.service,support_level" to describe a level of support | for a package and its contents.
So why not make the above 'opensolaris' attributes adhere to the same structure - e.g. opensolaris.org,maintainer.name?
| | 3.3. Attributes best avoided built-on release One problem we may run into is packages that have been built on arelease newer than that on the image. These packages should be evaluated as unsuitable for the image, and not offered in the graph. There are a few ways to handle this case:1. Separate repository. All packages offered by a repository werebuilt on a known system configuration. This change requires negotiation between client and server for a built-on match condition. It also means that multiple repositories are needed for a long lifecycle distribution.2. Attributes. Each package comes with a built-on attribute. Thismeans that clients move from one built-on release to another triggered by conditions set by the base package on the client. Another drawback is that it becomes impossible to request a specific package by an FMRI, without additional knowledge.3. Additional version specifier. We could extendrelease,branch:timestamp to release,built,branch:timestamp--or fold the built and branch version together. Since the built portion must reserve major.minor.micro, that means we move to a package FMRI that looks like[EMAIL PROTECTED],5.11.0.1:timestamp This choice looks awkward. We could instead treat the builtportion as having a default value on a particular client. Then the common specifier would be[EMAIL PROTECTED],build]-branch:timestamp build would be the highest available valid release for theimage.The meaning of the built-on version could be controversial. Asimple approach would be to base it on base/minimal's release, rather than uname(1) output.
First of all, I'm not sure what the name of the attribute is that you are describing here, nor why it is 'best avoided' - maybe (if it is needed), it should be a generic 'pkg' attribute ? As an alternate option, what about an attribute which defines the minimum version from which this package is upgradable from? Trev
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
