Please see inline.
Shawn Walker wrote:
Tom Mueller wrote:
Shawn,
This still doesn't say how policies relate to the existing
properties. Do policies and properties share the same namespace? If
no, are existing properties that are policies move to be policies? Is
the per-publisher property namespace shared with other publisher
attributes? (e.g., can I have a publisher policy called "origin"
that is separate from the origin attribute)
As I said before, the namespace issue is not within the scope of this
proposal and is something that will be handled by upcoming changes to
the ImageConfig object/class and file format.
It needs to be in scope. This is part of the definition of the
interface. For example, if one does:
pkg set-property my-policy true
pkg set-policy -n my-policy -v false
pkg property
What will be the output?
Also, if one does:
pkg set-property send-uuid true
pkg policy -n send-uuid
What will be the output? What will be the behavior of the HTTP requests?
With that said, I do not anticipate that properties and policies will
share the same 'space' within the new ImageConfig.
Given that, what happens to the existing policies that are represented
with properties?
Since it wasn't addressed, I'll repeat my request for an API that
will allow one to tell whether a license action actually has a
"must-accept" value or if it defaulting to false, for the reasons
already stated (To allow a client to preserve behavior for old
packages).
I must have missed the request for an API; all that I saw was some
discussion that you wanted to continue to have certain packages
require acceptance for their licenses.
However, since the must_accept attribute is intentionally optional (to
avoid unnecessary bloat in manifests), I don't believe it is possible
to provide the API you request since the resulting logic would be faulty.
As I said before, it is difficult to provide compatibility with
behaviour that was designed and implemented completely outside of the
pkg(5) system.
I'm not asking you to provide compatibility. I'm asking for visibility.
I really doubt manifest bloat is a problem for licenses, given how few
there are.
It would be nice if there was some symmetry between the set-policy
and set-property subcommands. Currently set-property doesn't use -n
and -v options for the name and value, those are just arguments.
Same for unset-policy and policy.
It is intentional that there is no symmetry between set-policy and
set-property, out of necessity. Namely, that properties are not
publisher specific, while policies can be.
The proposed policy subcommands as far as I can see, are consistent
with each other.
The need for publisher-specific policies is questionable, and certainly
not a reason for making the commands dissimilar. The "-p" could still be
an option. And if there are publisher-specific policies, then
set-property should probably have a publisher-specific case too.
Also, we certainly do not need the ability to set multiple policies in a
single command. That is just feature bloat, with the cost being
inconsistency with the set-property command. Let's keep the interface
simple.
BTW, are you going to prevent setting policies as publisher-specific
when they are not publisher-related policies? For example
"flush-content-cache-on-success" isn't publisher-specific - at least it
isn't implemented that way now.
Thanks.
Tom
Cheers,
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;Update Center Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[email protected]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
