On Jun 24, 2009, at 2:07 PM, Tom Mueller (pkg-discuss) wrote:
To support license acceptance functionality, new attributes for
license
actions are needed to allow packages to provide guidance to
pkg(5) client
api consumers:
must-accept A boolean value indicating whether this license
must be
accepted by a user before the related package
can be
installed or updated. Acceptable values are
"true" or
"false". Omission of this attribute must be
considered
equivalent to "false".
In updatetool, we've been implementing the default behavior of
"true", understanding that pkg(1) has always implemented a default
behavior of "false". I'm wondering if maybe when the tag is
omitted, the value could be "depends on the client" or "undefined".
The default behaviour should not be true. Packages with licenses such
as the 'CDDL' or 'GPL' do not require acceptance, and clients should
not be prompting for it. Acceptance of a license should solely be
determined by the guidance provided by a package creator and image
policy and/or user interaction.
must-display A boolean value indicating whether the content
of the
action's payload must be displayed by clients
during
packaging operations.
What is the default value?
Omission of this attribute must be considered equivalent to "False."
Only image policy or explicit user interaction should alter this
behavior.
To accomplish this, the following new attributes will be stored
in the
image configuration on a per-publisher (and/or global) basis:
Will the global attributes be stored in the [property] section of
the cfg_cache file?
Presumably the per-publisher value overrides the image value, right?
Actually, the license acceptance work has an implicit dependency on
the revamp of the cfg_cache format which will be happening in the near
future. I specifically avoided mentioning the storage format of the
configuration as the ImageConfig class handles that transparently.
Before that happens though, I will be adding image versioning because
the cfg_cache change will cause a completely incompatible break
between new images and old clients.
The new cfg_cache format will be json-based just as .p5i files are.
license-policy A keyword indicating what the behaviour of clients
should be when the license of a package requires
acceptance. The following keywords are supported:
accept Automatically accepts any license with
must-accept=true after license
filtering
has been applied.
decline Automatically declines any license
with
must-accept=false after license
filtering
has been applied.
explicit Requires explicit acceptance of any
licenses with must-accept=true by
the user
after licensing filtering has been
applied.
This could be implemented as an
interactive
prompt, or by a failure of the
client with
a requirement to pass an explicit
command-
line option for acceptance.
Presumably explicit is the default value if the policy is not
specified?
Correct.
license-accept A list of license keywords that will be used to
mark any
corresponding licenses as accepted automatically
if they
require acceptance.
license-decline A list of license keywords that will be used to
mark any
corresponding licenses as declined automatically,
regardless of whether they require acceptance.
Default values for these are empty, right?
Correct.
6.1. pkg(1)
The pkg(1) client that pkg(5) provides needs to be enhanced to
provide
the following functionality:
* Explicit acceptance of licensing terms for package operations
A new command-line option as shown below will be added to the
install and image-update subcommands:
--policy license=(accept|decline)
It is intentional that command-line overrides of the license-
accept,
and license-decline image properties are not provided. This
option
is named '--policy' in anticipation that there may be other
policies
that a user may wish to control during a packaging operation
in the
future.
Here, the policy keyword "license" doesn't match the name of the
policy "license-policy". But below, the keyword "license-display"
matches the name of the policy. It seems redundant to use --policy
license-policy=accept, but it might be nice that the values passed
to the --policy option are all policy names.
Correct, this is something I missed last night. Consistency is
preferable over avoiding redundancy.
* A set-policy subcommand will be added to allow setting policy
values
that functions as follows:
set-policy [-p publisher] -n policy-name -v policy-value
If -p is not provided, the policy value is considered global.
Currently, policies such as "flush-content-cache-on-success" are
set, unset, and displayed with the set-property subcommand.
Policies are just properties that have a boolean value. Do we
really need to add these policy subcommands?
It seems better from a user perspective to call these 'policies'
instead of 'properties'. At least, more understandable anyway. I
wouldn't be opposed to simply renaming property, set-property, unset-
property to set-policy, unset-policy, policy.
I'm open to suggestions keeping in mind clarity.
Is the [policy] section of the cfg_cache file going to be
reintroduced?
See above, ImageConfig manages the configuration and is outside the
scope of this.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
