Shawn Walker wrote:
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.
Normally I would agree, except that in this case, some properties would
be become policies (per the list you mention below).
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.
Now, "pkg set-property send-uuid true" (or false) changes the behavior
of all HTTP requests. After your change, will it? I assume not. So
this definitely is a change in the behavior of 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?
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.
Can you suggest even one? Short of parsing the manifest file, how can
we preserve the existing behavior for old packages that do not have
must-accept=true?
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.
Not sure what you don't agree with - I assume it is the part about
needing publisher-specific policies for licenses.
Do you also not agree that "-p" could be an option while the name and
value are arguments?
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.
Please make it a focus. This is essential for overall usability.
The more I think about it, the more important it is to have symmetry
here. It is extremely frustrating to use commands that have seemingly
arbitrary differences in command options/arguments between different
subcommands. Image if we had -v for verbose on one command and -e for
extra detail on another. Or if the package name on "install" was an
argument but it was a -p option on uninstall.
Another example is that in set-publisher, the name of the publisher to
change is an argument, not an option.
Generally, options should be options, i.e., optional. For set-policy and
unset-policy, the name and value are certainly not optional.
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.
Not useful enough to justify an inconsistency, especially when there is
an easy way to write the script without that.
Regards,
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
