[pkg-discuss] License Acceptance Functionality Proposal [Take 3]

[Tom Mueller]

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,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Tom_Mueller.vcf
Type: text/x-vcard
Size: 309 bytes
Desc: not available
URL: <http://mail.opensolaris.org/pipermail/pkg-discuss/attachments/20090701/720e389e/attachment.vcf>