Tom Mueller wrote:
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?
I'll add example output.
Also, if one does:
pkg set-property send-uuid true
pkg policy -n send-uuid
Since there is a separate subcommand for these, I thought it was logical
to assume that you couldn't use policies with properties and vice-versa.
I don't think it is necessary to explicitly state that a completely
disparate subcommand would alter data unrelated to that subcommand.
What will be the output? What will be the behavior of the HTTP requests?
The behaviour of HTTP requests has nothing to do with the changes
proposed here as no change proposed here affects HTTP requests to my
knowledge.
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?
As for which properties will become policies, I'll add the explicit list
to the text.
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.
The visibility provided is based on the functionality provided. As I
said before, as long as must_accept and must_display are optional, there
is no reason to provide what was requested as the resulting use of that
logic would be faulty.
I really doubt manifest bloat is a problem for licenses, given how few
there are.
The point is to avoid specifying attributes unless they need to be. I
see no reason to have a must_display=false must_accept=false on every
single license action other than to preserve compatibility with
functionality not provided by the pkg(5) system. For a single package,
it may not represent much, but in aggregate, it is much harder to ignore.
Since the only reason this is an issue is because of a design choice
made by a consumer of the pkg(5) system, I think it should be resolved
by that consumer since there are many options available to do so without
design intervention here.
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.
I do not agree. Since licenses and related documents are about a
relationship of trust, I anticipate that some users will choose to trust
licenses from some publishers, but not others. I believe that
empowering users for themselves is the appropriate course of action.
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.
Consistency between disparate subcommands is not a focus for me. I
believe that from a scripting or other perspective, it will be useful to
administrators to specify multiple policy values using a single
invocation of the pkg command.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
