[packagekit] Packagekit and Ubuntu

[Richard Hughes]

2009/9/17 Michael Vogt <mvo at ubuntu.com>:
> My understanding of your position has been that you will not support a
> mechanism like debconf. Debconf provides localized questions and a
> abstract UI based on a simple protocol. Its used to ask basic
> configuration question before (and sometimes during) install. It
> supports gnome and qt frontends. The Debian world (that includes
> Ubuntu) quite likes debconf.

Right, I agree debconf allows you to do some clever things, but I
disagree with some of the logic behind letting the packager ask the
user the most random questions. Given that debconf supports a
non-interactive argument (and thus choosing defaults where possible)
it's only the broken packages that don't use debconf we really have to
worry about.

> The reason why its useful to ask configuration file changes
> prompts during the install is that when a daemon restarts, it makes
> sense to restart them with the new config (if the users wants that).

The type of user that is using PackageKit GUI tools doesn't want to
restart random services, the typical user either wants:

a) the service to be restarted automatically if possible
b) just a notification that they have to logoff or reboot.

> In the aptdaemon project (that was written by Sebastian and draws a
> lot of inspiration from PK) deconf support is integrated.

Right, and aptdaemon will have a lot of problems because of it. As
soon as you have fast-user switching, multiple users per computer then
the concept of a "stuck" transaction waiting for input is an obvious
denial of service. I'll elaborate.

User A has permissions to update the system or install codecs (desktop user)
User B has permissions to do anything (admin)

User A finds out about a remote exploit in openssl, and knows there is
a new package on the mirrors that will fix this remote exploit. User A
starts installing a package with a EULA and then locks the computer
and walks away.

User B wants to update openssl to prevent the remote exploit, but
can't access apt or any of the apt tools as the EULA dialog is showing
in user A's session. User B can't kill the process (and lock) held by
user A (as the package would be neither installed or removed) and has
no options other to find user A and get him to login, and click OK on
the EULA screen.

The same problem is true when automatic updates are being applied when
the user is idle, and thus not at the console when the update script
asks the user a question. Keeping a computer up to date should not
involve packaging questions.

With the PackageKit way of doing it, the EULA screen would not block
the daemon, and user B can use apt as he pleases, and automatic
updates can be done successfully. When user A returns, he clicks OK on
the EULA dialog and the install continues. No lock is held in this
model.

> I'm absolutely willing to work on adding that to PK if there is a chance
> of this getting accepted. Even if its just a deb-systems-only option.

Sure, if you're willing to work on it, then I'm willing to review it.
If your patch involves adding a file descriptor to a root vte window
on every public method then it's not going to be acceptable. If you
find a way to handle debconf out of band, that would be great.

> This has been discussed in the past and you expressed that you do not
> want any sort of interaction during a transaction as a policy
> decision. Its documented:
> http://www.packagekit.org/pk-faq.html#hughsies-law

Sure, but you can requeue the transaction as many times as you like.
In the glib2 bindings all the requeuing is done automatically, so an
application just has to call pk_task_install_packages and all the
interactions are dealt with. I don't care how many questions (or type
of questions) are asked when the sub-transaction is finished.

> This does not map well to the deb package world. Of course your
> reasons are valid, in 99% of the cases it is not needed and the end
> user does not care. But we do want to cover 100% of the packages,
> especially since the goal is to cover updates (that can be any
> packages and not just applications) and generic packages as well. Most
> users won't ever see a debconf dialog, but if the packages requires
> it, then it should be there.

I've talked to many people about this, and people were basically stuck
in two camps:

1. Let debian do it, they are too big to ignore even though it will
hurt the API and the project
2. Don't let them bully you into making PK just as bad as what was
previously done

So if you can find a way of doing debconf in a nice abstract way (so
that it can be upstream) then I'll commit it. If it's a cheap hack
that breaks all the existing tools then I'll obviously have to say no.

> This is because of the points mentioned above. It can be debatted if
> the deb format should change and/or if debconf is a good idea or
> not. But if we want to provide a way to install every valid deb
> package  (including the packages that require debconf) now, then
> PK is not a option (and that is unfortunate).

I don't think debconf is bad, I just think most of the questions it
asks are meaningless. Take this dialog as an example:
http://people.freedesktop.org/~hughsient/temp/Screenshot-3.png

> I do not think the reason is "its too hard". Its about the PK policy
> being incompatible with the Debian/Ubuntu policy.

There is no PK policy. The rules PK sticks to get bent, changed,
modified almost as much as it's API. As people on this list have seen
I'm not frightened of breaking ABI or API to include a feature that a
backend needs. But I do need a long term goal, else PK becomes an
unmaintainable mess, and that long term goal is set by the three
people on the profiles page
[http://www.packagekit.org/pk-profiles.html] -- these are three very
real people (friends and family of mine) and are not theoretical in
any way.

> If there is a chance that debconf support would be accepted I would
> certainly be interessted in working on this.

Sure, as I've said above, if it's a clean solution to a technical
problem then I would welcome it with open arms (and even buy you a
beer to two) -- if it's just linking a VTE widget running as root into
each transaction then I'm obviously not that keen.

Richard.