[packagekit] Handling of License Prompts

[Richard Hughes]

On 11/09/2007, Tom Parker <palfrey at tevp.net> wrote:
> 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
> impossible [0].

Great....

> 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
> [1] 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.

And probably not a priority for the debian guys...

> > PackageKit will not open a console for the input or output of any
> > package
>
> Ah. That's going to be a problem. See section 6.3 of the Debian policy
> manual [2], 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.

Well, we can try. The very nature that this interaction is guaranteed
scares me a little.

> 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).

Yes, this what we need to do.

> What that should do is pick all the safe options for us, which is nice.

Cool.

> 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
> from EULA-failures.

Agreed, a different error code is required.
InstallPackageEulaAgreementFailed or something.

> The non-interactive frontend may in the future [3] 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

Yes, for packages that need a EULA on install (broken packages) we can
legitimately fail the install. Seriously, concentrate on making the
PackageKit apt backend work with free software. If it works with
binary-only crap then that's a bonus. We need to refocus on making 99%
of packages work rather than get hung up on the non-interesting broken
software.

> (short of writing a new Debconf frontend. Grr, arrgh, Perl.) is
> non-trivial.

Perl. Ick.

> And I wonder why I put off building the Install action for the apt
> backend....

Heh. Dude, like I said, if we only install packages that don't ask
questions, that still competes the majority of the use cases. If an
admin is installing vmware, then I'm sure they are more than capable
of dropping to a command line.

Richard.