Some changes to the license action are needed to implement the following
RFEs:
5586 licenseinfo api needs to expose license action attributes
5732 packagemanager should have support for click-thru license
5943 'must_accept' attribute desired for license actions
This proposal is based on sch's proposal and the resulting discussions [1].
========================================
Proposed Changes
========================================
* add a new boolean attribute named 'must_accept' to the license action,
which defaults to "false".
* add 'must_accept', 'license', and 'text' properties to the
pkg.client.api LicenseInfo object
* add a license-policy image property with possible values as follows:
-- accept - would accept any license with "must_accept=true"
-- decline - would decline any license with "must_accept=true" (default)
-- prompt - would prompt the user to accept each unique "license"
* add a --license-policy parameter to the install and image-update
subcommands of pkg(1). If not provided, the image configuration's
license-policy property value would be used instead.
* pkg.client.api plan_install and plan_update_all would be changed to
include a "license_policy" parameter. License information would then be
retrieved during PlanDescription creation for packages based on
license_policy as follows:
-- accept - would not retrieve any license information and allow plan
creation to continue as it does today. At the end of plan creation, the
plan's must_accept_license property would be set to False as all
licenses were explicitly accepted.
-- decline - would add a LicenseAcceptanceFailure exception with an
attribute "package" that would allow access to the corresponding
PackageInfo object, if any "must_accept=True" license actions are
encountered, to an errors list. At the end of the plan process, a
single LicenseAcceptanceFailure exception would then be raised with the
text of all of the LicenseAcceptanceFailure exceptions concatenated and
an attribute of "packages" on the object would allow access to a list of
the PackageInfo objects for the packages that needed license acceptance.
-- prompt - would add retrieved license information to any PackageInfo
objects created during PlanDescription creation with "must_accept=True"
on their License actions allowing client to obtain it using
ImageInterface.describe().get_changes() (which returns a list of
PackageInfo objects which have a license property for accessing the
information). At the end of plan creation, the plan's
must_accept_license property would be set to True if any
'must_accept=True' license actions were encountered.
* add a licenses_accepted (default False) boolean parameter to
pkg.client.api execute_plan method. execute_plan would check
self.must_accept_license, if it was True, then the licenses_accepted
parameter would also have to be True. If False, a
LicenseAcceptanceFailure would be raised as described above; otherwise
plan execution would continue.
* change pkg(1) to check for plan.must_accept_license after plan_install
and plan_update_all. If True, it would then prompt or raise an
exception depending on the provided --license-policy or the image's
license-policy. If the policy was to prompt, then each unique license
would be displayed (along with the list of corresponding packages) and
the user would have to answer "Yes" or "No" (explicitly). Answering
"No" to any prompt would assume "No" for all remaining licenses and
raise a LicenseAcceptanceFailure exception as described above. If
plan.must_accept_license was False, or the user accepted the licenses,
it would then call execute_plan().
* change pkg(1) to have an exit code of 4 if a LicenseAcceptanceFailure
exception occurred. When exiting (due to this failure), pkg(1) would
also be changed to display the list of unique licenses that were not
accepted and the list of corresponding packages. The operation would be
recorded in image history with a result of "Failed (Licenses)"
* update pkg(1), pkgsend(1), and pkg(5) man pages to reflect changes.
====================
Unresolved Issues
====================
* Implementing these changes would constitute a flag day for consumers
of the pkg(5) api and pkg(1). This might an undesirable impact on
projects such as the automated installer, etc. depending on which
packages had 'must_accept=True' set on their license actions. This may
require delaying the implementation of this functionality until after
2009.06 (business requirements permitting).
* Retrieving the license information as I described above would incur a
hidden download time for users while licenses were retrieved from the
server (if not already downloaded). This means that a download phase
might have to be added just for plan evaluation (which is eventually
needed for manifest retrieval, so this seems moot).
* Client memory usage for the plan creation phase would be increased
when the license-policy was "prompt" or "decline" depending upon the
number of licenses that have to be retrieved. In addition, the plan
creation phase time would also be lengthened due to the remote retrieval
of license information (if needed).
Cheers,
--
Shawn Walker
[1] http://markmail.org/message/uu3vpraxlgjld6dr
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
