Stephen,
A couple of topics to consider in the scheme of attributes and perhaps
actions:
Indicating Security Related Updates
========================
I don't recall reading a discussion of identifying a package as
delivering one or more fixes to security related issues. One use case is
where a desktop notifier would highlight such security fixes to the
user. (I'm certain that other use cases exist. Such as a browser
interface to hosted management services in which the nature of updates
that are applicable to an image would naturally highlight
security-related fixes.)
This highlighting is typically available in Linux distros and other
software update facilities.
What's your opinion on supporting this information? Might it relate to
the change history feature that Tom is pursuing in that the tools could
detect the presence of one or more security fixes? i.e. the ability to
display summaries of key changes made within each version of a package.
Ownership and Precedence of Classification
=============================
Tom wrote earlier about our interest in enabling the distro/repository
owners be able to override categorization data as supplied by a package
maintainer, but I haven't seen a response to this interest. We'd rather
not have to force republishing of packages just to be able to properly
organize them in the client GUIs. (ccing Michal for his latest thoughts
as well). We need a resolution on this topic because as we add support
to the UC GUI for the info.classification attribute, we need to know if
we should drop the authority-level categorization approach that we
cribbed from the Package Manager GUI. Do people generally agree that
providing an option to override classification by supporting a per
authority mapping feature makes sense?
Here's Tom earlier comment:
While it might be possible for package developers to choose among some
set of well-defined labels for categories, for the Update Center GUI
tool, we've been assuming that categorization of packages will largely
be the responsibility of the distribution assembler, i.e., the person
who decides what packages will be made available in a repository. So in
addition to package developers providing gui.classification attributes
with packages, we are making use of some categorization data that is
delivered into the repository as a separate package. The GUI tool can
then leverage that data as well as the data provided by the package.
Thanks,
Chris
Stephen Hahn wrote:
> (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
>
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
