[packagekit] Handling of License Prompts
palfrey at tevp.net
Tue Sep 11 14:44:40 PDT 2007
Richard Hughes wrote:
> Okay, do you mean the backend should emit a signal
> LicenceNotice(s=string) during the transaction, and then the UI gets
> shown at the end of the transaction? If so this is easy to add.
Oooh boy.... this will be nigh-on impossible to do for apt (at least
with the dpkg backend i.e. Debian/Ubuntu/derivatives). EULA's are a
question in a debconf script, which is an arbitrary block of perl or
shell script (actually, it can be pretty much *any* executable
thing...). There is *no* way to tell that a particular question is an
EULA, and even telling that a package *has* a clickwrap license is
There is the debian/copyright file in the packages, but the formats for
that are badly defined and a bugger to machine parse. There's a proposal
 to improve this, but don't hold your breath, and "evil-eula-license"
isn't a class of license being considered as a field option currently.
> PackageKit will not open a console for the input or output of any
Ah. That's going to be a problem. See section 6.3 of the Debian policy
manual , specifically the text that says "The maintainer scripts are
guaranteed to run with a controlling terminal and can interact with the
user". I'm not sure whether a lack of a true controlling terminal will
break many things or not.
On the other hand, it appears to be possible to tell Debconf (AFAIK
pretty much the only used Debian configuration tool, which reduces the
level of true "user interaction" down a bit) to go non-interactive, so
we could hide something that pretends to be a console deep down out of
sight (which is what the synaptic APT client does to a certain extent).
What that should do is pick all the safe options for us, which is nice.
However, in the case of EULAs that should always be "I don't agree", so
we'll get those packages looking like they had an installation failure,
and I'm not sure how to go about separating proper installation failures
The non-interactive frontend may in the future  output stuff to
stderr saying why something has failed, but we should be able to feed
that back through the ErrorCode signal. Hopefully that might include
useful things like "you didn't agree to our EULA", so at least there's
some feedback, but catching those and going back and doing the thing we
want (short of writing a new Debconf frontend. Grr, arrgh, Perl.) is
And I wonder why I put off building the Install action for the apt
0) Well, we can eliminate large categories of packages, and only stuff
under the "non-free" or "contrib" category (or *any* non-Debian/Ubuntu
package source) can potentially be EULA stuff. But, that's a fair block
More information about the PackageKit