(So this response is further along, and seems timely to send...)
Although in the old days, I would take the feedback received,
synthesize it, and emit a new version of a document, I think that
might be too abrupt. So I'll take the intermediate step of trying
to summarize what I think the impacts of the received questions and
comments are, prior to that writing phase.
Thanks for all of the comments so far
Stephen
----
1. Consistent use of tags and attributes. Danek noted that the
source code reverses the definitions relative to the draft, so
that tags are upon packages and attributes upon files. I think
we should change the document to match the code.
We also need to note that the "set" actions sets a package level
tag/attribute.
2. Forward vs reverse domain names in tag/attributes. Reverse
domain names it is. This means that private properties are
com.example,property_name:locale
3. pkg.name vs pkg.summary. The short descriptive name is a one
line displayable string about the package. It's not useful with
either the Python or scripting APIs as a distinct identifier for
a package, so it's not a great "name". pkg.summary seems fine.
4. The OS-specific namespaces. A couple of questions came up
regarding the "opensolaris." prefix. Tom pointed out that many
of these attributes were applicable to software he plans to see
published for other OSes. I hadn't expected the commonality to
be so high, but because it is, I propose we introduce the "info."
namespace for this more optional metadata.
(There was also a question about why "opensolaris." and not
"org.opensolaris." for these properties. The point of the
OS-specific namespaces was to develop distribution-level
conventions; org.opensolaris is expected to be used by projects
and consolidations publishing within an opensolaris.org
authority.)
5. Author vs upstream. Author seems easier to understand.
List-valued is fine, but I believe that means we'll need
primary_author. Shawn gave an example of multiple upstreams, but
I have to confess I wasn't convinced--either the immediate author
wants to be treated as an originator, or they will refer to
themselves as the maintainer.
6. Version in description. In the original draft, I made a point
about keeping the version out of pkg.summary, but allowing it in
pkg.description. As I hint at in #3 above, the summary string
is expected to be used by all browsing/reporting interfaces for
human consumption. The intent is to confine those humans'
expectations about upgrade to the sequences of versions in the
relevant FMRIs. So the expected per-package browsing display is
pkg.summary and the version portion of the FMRI.
info.author_version, which would contain the author's
conventional version for the package, seems useful to me, too.
7. Unicode. Values: yes, someday. Property names: no.
8. pkg.debug and pkg.compatibility. These are action modifiers, not
package modifiers--they are used to distinguish which of two
otherwise similar actions are delivered when the filters acting
on the package include some statement about these tags. For
instance,
file [H_1] path=kernel/amd64/genunix arch=amd64 pkg.debug=true
file [H_2] path=kernel/amd64/genunix arch=amd64
file [H_3] path=kernel/genunix arch=i386 pkg.debug=true
file [H_4] path=kernel/genunix arch=i386
with pkg.debug set to false would get the files H_2 and H_4 at
the identified paths.
(I believe this aspect came up during a discussion of a possible
doc (or pkg.doc now) tag as well.)
A different question is whether there should be a package level
attribute that summarizes the delivery choices a package
presents, but that may be easier to synthesize/calculate than
express.
9. Package to ARC case linkage. A number of good points were raised
on this idea. The most complicated aspect is maintenance across
package splits and recombinations, which I don't have a good
answer for, beyond what I'll outline next. Based on #4, these
properties would be prefixed by info.
These properties would be optional, like most info. properties.
Although Danek preferred using the case ID to an actual URL,
that preference forces each agent to encode a conversion
function. Perhaps we can get a stable URL scheme in place for
ARC cases soon.
My expectation is that consolidations would ask projects to
associate the most recent case or cases with the component, and
that linkage to the preceding cases would come from the ARC
record. (I suppose it could be determined from the package's
version series as well.) These package-case associations will be
built up over time. (I am assuming we will split SUNWcsl and
SUNWcsu in any case.) I'll try to work through an example.
10. Package to SCM linkage. Since we don't have
consolidation-spanning packages, these should be easier than the
ARC linkage--some changeset must have produced this version of
the package. It's probably obvious, but this data is needed for
software maintenance, whether you do much of the analysis
yourself or interact with some support provider. The terms,
"repository" and "changeset", apply to Subversion as well; we
could use "revision", but publishers using non-changeset oriented
schemes are probably using tags, branches, or freezepoints.
("scm" seems opaque.)
11. opensolaris.gui.classification. Like the other properties in
opensolaris., this one moves to info. Dropping ".gui."
is fine, since I'm sure other utilities can consume this
information. If someone knows of a standard classification, now
would be a good time to suggest it--I spent some time reviewing
various distro schemes, but have no conclusions.
Product-specific tools can of course introduce a private
classification, but UC and PackageManager need to be able to
share a classification space on OpenSolaris-based systems.
12. license as attribute. The license action is currently needed
because it delivers a payload, but the point on filtering is
important. We need to discuss whether we need pkg.license and
to change "license" to "meta ... type=license ...".
13. Directory tags. Yes, all actions can carry tags. Yes, filters
should affect these actions, too.
14. Icons. I'll need more use cases/justification of why these need
to be actions. (How would you identify different icon sizes and
types?) My preference is to make this kind of information a URL
tag/attribute, and move responsibility to the client. (Since
every published file has a URL, that's not as big a deal as it might
appear...)
15. Additional tags. Yes, we need to attach tags as packages get
through additional assessments. What's less clear is whether
some of these are, in fact, Solaris or Sun only--like Section 508
(USA accessibility law)--or of broader interest.
com.sun,assessment.section508
com.sun,assessment.open-source
[info.arc_url]
where each of these carries a URL or identifier (potentially only
of use to the publisher).
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
