Tom Mueller wrote:
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?
Why would you assume that? Where did I mention anything about
send-uuid? The HTTP behaviour of send-uuid is specific to the transport
system and is not something that any of these changes will be able to
affect at all. I will state again, to my knowledge, there will be
change to the existing behaviour of HTTP requests. What the transport
layer chooses to do or not do with HTTP requests is not within the scope
of this proposal.
The most indirect effect that I could possibly extrapolate is that if
send-uuid is made publisher-specific (which this proposal has not yet
suggested) that may affect what the transport subsystem decides to do
with HTTP requests.
In short, I feel it is out of scope to describe what a particular
subsystem may or may not do as a result of policy values, especially
when I am not altering that subsystem.
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?
I could have made lots of suggestions if we had been asked originally
that would have avoided the current situation, but since those questions
weren't asked when the updatetool design decisions were made, it is a
bit difficult at this point.
Again, I will say that parsing the manifest in the way you suggest, or
an api that could be provided, would result in faulty logic.
Your best option may be to simply to ignore license policies and
continue to force your users to see and accept all licenses as you
already do that today even when the license doesn't necessarily require it.
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.
Correct.
Do you also not agree that "-p" could be an option while the name and
value are arguments?
I never said that it couldn't be, but I maintain that having explicit
arguments for name and value is preferable from a parsing and
convenience standpoint as noted below.
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.
We'll just have to agree to disagree on this particular point. The
pkg(1) command already uses the same options for different uses for
different subcommands and for the same reasons that was allowed to start
with, I see no reason to deviate here.
A possible compromise here would be to make -n and -v optional, but
somehow I don't think that would be a favourable outcome.
I will await feedback from others.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
