David Powell wrote:
Shawn Walker wrote:
Shawn Walker wrote:
Shawn Walker wrote:
pkg(5): image packaging system
LICENSE ACTIONS ACCEPTANCE PROPOSAL
There are actually two points when we might need to display or
require acceptance of package licenses. One is when the user
themselves installs a package requiring display or acceptance of its
licenses (which appears to be adequately covered by your proposal),
and the other is when a user first turns on a computer pre-installed
with packages under a license that requires display or acceptance
[1]. In the latter case installing the software doesn't imply
acceptance, acceptance is something that needs to be obtained at a
later point in time.
There seem to be conflicting requirements here. That is, some software
seems to require acceptance before you can even "copy the bits" onto a
system in a useable form, and another that you have mentioned here where
"acceptance" can be deferred until a later date.
However, from a packaging system perspective, one the bits have been
delivered onto the system, it's too late to enforce license acceptance.
The only thing we can do is "record" license acceptance information.
With that said, I could see possibly introducing an additional state for
licenses that could be recorded in the package license state information
such as "deferred-accept".
I also agree that a "deferred-accept" seems appropriate for automated
installation or other cases.
However, that does mean we need an additional subcommand to alter
package status (specifically, license acceptance status) and an
appropriate client api interface.
Once that was added, a visual panel could handle the first boot license
acceptance and use the client api interface / cli to set status as
appropriate.
This goal:
* Enablement of administrators and users to query and report on
the licensing or other informational data related to packages
contained within an image
seems like it might meet this need, but the enhancements to "info"
fall short of it.
After the proposed changes, with "info" I will be able to view all
licenses concatenated together in a human-readable format, and with
"contents" I will be able to examine the attributes associated with
an opaque list of licenses. Unfortunately there's no way to
associate the licenses themselves with their attributes, which makes
any solution to the pre-install problem clunky at best.
The output of "info" is not intended to be parseable.
If you need detailed consumption of package information, that's really
best done via the python pkg.client.api using info() instead of
attempting various gyrations via the cli.
With that said, I'm open to a long-term RFE to allow the info subcommand
to have a parseable output format.
I'm not expecting an elaborate or even complete solution to the
pre-install problem; we just need the tools that would permit
implementing one in a supported fashion. As far as I can tell, the
only missing piece is the ability to get the text of a specific
license action delivered by a package.
I don't know that you need the text of a specific license action so much
as you need the list of licenses and their text in a parseable format as
I dsecribed above.
Your feedback was quite valuable, and in retrospect, the cases you
present here seem so obvious that I'm surprised I missed them.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
