Danek Duvall wrote:
On Fri, Mar 13, 2009 at 04:17:42PM -0500, Shawn Walker wrote:
* add a new boolean attribute named 'must_accept' to the license action,
which defaults to "false".
I'd like to start naming attributes with dashes instead of underscores.
I also wonder if there's more than just two possible license policies here.
I know there are some installation programs which force you to scroll all
the way to the bottom of the license before you can accept it -- presumably
whoever thought of that wouldn't want to allow the "accept" policy, and
force you to read it or decline it.
It hasn't been requested, so I don't think we need the rails for it :)
* 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.
Do we envision wanting to set other policies at install time? If so,
perhaps "--policy license=<value>" might be better here?
That would be fine; I was just taking dp's suggestion.
====================
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).
I'm not arguing for inclusion in 2009.06, but I think the practical impact
is going to be pretty small -- only the packages in extra are likely to
want this right now.
That was my thought; it doesn't matter to me whether this is 2009.06 or
not, although the window for that is rapidly shrinking.
* 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).
I don't think this is a big deal, as you point out. You'd only see a
license-only download when someone had done a pkg install -n previously.
So retrieving the license information at the same point we retrieve
manifests would seem reasonable?
* 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).
Again, I don't think this is a big deal. You can invoke gzip and $PAGER,
if it exists, to read the file out of the download cache. The memory
involved here shouldn't be terribly large.
That's an interesting (and preferable) approach. That is, instead of
loading the license text, having each exception provide either an
opener() that returned a file object to stream the content, or providing
the path to the file itself. In either case, I would expect a str() of
the exception to have the same effect.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
