On Mon, Mar 31, 2008 at 4:07 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > | PSARC/2008/190 > | pkg(5): image packaging system > | > TAGS AND ATTRIBUTES > > 1. Definitions > > | Both packages and actions within a package can carry metadata, which > | we informally refer to as attributes and tags. > > Attributes: settings that apply to an entire package. Introduction > of an attribute that causes different deliveries by the client could > cause a conflict with the versioning algebra, so we attempt to avoid > them. > > | Tags are the settings that affect individual files within a package. > | Tags may eventually have values, depending on how many tags are > | required to handle the SPARC-based platform binaries. > > | 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. The name field is a > | The default locale, if the locale field is omitted is "C", a 7-bit > | ASCII locale. > | > | Each of these fields is [A-Za-z][A-Za-z0-9_-.]*.
This seems to contradict the previous statement regarding the locale field. In locales other than "C", then, I assume other characters are allowed? > | 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" > | > | pkg.description > | A descriptive paragraph for the package. Exact numerical version > | strings can be embedded in the paragraph. Can you clarify what the intent is behind establishing policy for where usage of numerical versions matters? > | 2.3.2. Common tags > | > | 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 like seeing this as a codified tag. From my experience in managing packaging on RHEL (RedHat Enterprise Linux) systems, being able to easily install the "debuginfo" for a particular software package was a lifesaver when it came time to figuring out why apache core dumped :-) > | 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. This seems a little out of place. I would expect this sort of information to presented with the aformentioned "detailed_url" possibly. > | 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. I could be pedantic here and point out that you might have multiple upstream sources for a particular package. However, your intent here may be to only record the immediate upstream. For example, a "special" version of a utility or package that someone maintains that you decide to package that was originally authored by a different upstream source. > | 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. I'm concerned that the above attributes aren't flexible enough to deal with packages that may contain work from multiple repositories or sources. It might better to provide a more free-form way to record this information. Also, assuming a single repository_changeset implies a certain kind of source control system technology being used. Multiple changeset ids may apply depending on the system. These attributes might be more appropriate at the file level, or kept far simpler as mentioned earlier. > | opensolaris.gui.classification > | A list of labels classifying the package into the categories > | shared among pkg(5) graphical clients. I don't agree that labels classifying the package should be limited to graphical clients. I believe they can apply just as easily to a cli-based client. See dpkg on Debian. > | 3.3. Attributes best avoided > > built-on release > > One problem we may run into is packages that have been built on a > release 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 were > built 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. This > means 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 extend > release,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 built > portion 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 the > image. > > The meaning of the built-on version could be controversial. A > simple approach would be to base it on base/minimal's release, > rather than uname(1) output. I would be inclined to make each build provide a metapackage named after the build, and then have software that needed a specific build or newer depend on that. I agree that this should probably be avoided as an attribute. 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
