Danek Duvall wrote:
On Mon, Jul 06, 2009 at 08:36:11AM -0500, Shawn Walker wrote:
2. License Action attribute changes and additions
Currently, the license attribute of license actions is not
restrictive enough in what characters are allowed for the
name of the license. To ensure cross-platform compatibility
and consistent naming, it is proposed that the license
attribute's definition be amended as follows:
license The keyword identifying the license type, for use in
filter and query operations. The name of the license
should be limited to the characters [A-Za-z][A-Za-z0-9
_-.,]* as it is intended that only short, descriptive
text be used as the identifier for the license payload,
such as "copyright" or "CDDLv1".
I don't understand the reason for the restriction on characters. There are
a wild variety of licenses out there, including things like "GPLv2 with the
Linux Kernel exception", which can't necessarily be made more compact. I
definitely don't see how limiting the characters will ensure cross-platform
compatibility (or even what cross-platform compatibility means in terms of
a license), nor how it will ensure consistent naming.
The issue is primarily of storage by name where some characters won't be
allowed in file names or create other issues. I suppose that could be
handled just by enforcing URL-encoded filenames when delivering the
licenses into an image.
The hope also was that by restricting the valid set of characters it
would encourage consistent naming, but perhaps I was just being overly
optimistic.
In short, the point was that consistent names should be used to allow
users/administrators to easily define license policies and to allow more
compact presentation of license errors or licenses during packaging
operations.
It seems that you feel the guidelines are the best way to handle this,
so I'll simply remove this part about restricting the name.
license-accept A list of license keywords that will be used to
mark any corresponding licenses as accepted
automatically if they require acceptance. This
value is undefined by default.
I couldn't tell from this or the rest of the document, but it seems like as
proposed, no licenses will be accepted by default, which means ... what?
No package with a license will be installed by default? Or will licenses
be ignored unless the license action or the policy dictates it needs to be
paid attention to?
See license-policy 'explicit'.
license-accept is only used to automatically accept specific licenses if
they require acceptance. Think of license-accept and license-decline as
license filtering policies that get applied first to any licenses that
are relevant to the current packaging operation, and license-policy as
logic that gets applied to whatever is left after the filtering has been
applied.
I'll try to split this out a bit to make it more obvious.
* The ImagePlan object will have a new method named 'set_license'
which will allow callers to mark the explicit acceptance of a
package's license by a user:
set_license_status(fmri, license_keyword, status)
Typo: set_license()?
No, intentional. My thought was that set_license_status was clearer
than set_license.
A new global, command-line option as shown below will be added
to the pkg(1) client that will allow its usage with any sub-
command although policy values may not influence the behaviour
of it (e.g. --license-policy used with info).
--policy <policy-name>=<policy-value>
We've not been adding global options so far, though many could be. Will
this be ignored for subcommands for which it makes no sense? Or should it
just be added to the two subcommands (install and image-update, or are
there more) where it applies?
The idea was that it was global so that as we add policies in the future
that affect different subcommands that they would be applied
consistently or that as different subcommands are added or operations
are changed that they too would benefit.
In particular, I didn't want individual subcommands to be processing and
parsing this information; I felt that since it controlled the overall
behaviour of the client that it was preferable to specify it a global
level, and was easier to document, easier to explain, and would ensure
consistency.
* Graceful, informative failure due to license-related exceptions
pkg(1) will be changed to exit with return code 4 if a
license-related exception occurs during plan execution.
Why the special exit code? We don't have special exit codes for anything
else.
I don't remember where the feedback came from, but I'm not opposed to
removing this; will do so.
* A set-policy subcommand will be added to allow setting policy
values that functions as follows:
set-policy [-p publisher] (policy-name policy-value |
-v policy-name=policy-value)
Pick one syntax; we don't need both. I'd suggest the first one, and you
can just alternate names and values. Or you can do p-n=p-v p-n=p-v ....
Mostly what I had been trying to deal with is policy values with spaces
in them and not having the parsing 'suck' for that.
However, I see now that if the user does this:
pkg set-policy policy-1 'value 1' 'policy 2' value-2
Then that will be seen as only four arguments and it won't "split" at
the spaces (which is what I was thought it would so for some reason).
If they leave off the quotes of course, then things aren't so rosy, so
I'll just need to mention that in the man page. I'm not certain if
that's a getopt behaviour or a shell behaviour.
As such, I'm happy now with using the first syntax you suggested.
* An unset-policy subcommand will be added to allow unsetting or
resetting policy values that functions as follows:
unset-policy [-p publisher] (policy-name policy-value |
-v policy-name=policy-value)
Ditto here, though I don't get the utility of specifying the value.
Copy/paste error.
If -p is not provided, the policy value is considered global.
If -v is not provided, it is assumed that the policy name will
be provided, followed by whitespace as a break, and then by the
value for the policy.
Alternatively, -v can be provided so that multiple policy values
can be set
Huh, copy/paste?
Yes, sorry.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
