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.
With that said, I do not anticipate that properties and policies will
share the same 'space' within the new ImageConfig.
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.
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.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
