[packagekit] Packagekit and Ubuntu

[Michael Vogt]

On Fri, Sep 18, 2009 at 09:31:37AM +0100, Richard Hughes wrote:
> 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.

In some (rare) cases the sane default is to not allow the package to
get installed. This was the case for the virtualbox package at some
point where a new version would destroy the old snapshots. So using
sane defaults sometimes means a package can not be installed at
all. Admittedly those are rare cases, but we do want to support them
with our tools.
 
> > 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.

I agree with that for 99% of the users, but I would like to support
100% of our users. If its useful for more experienced users or setups,
then I don't see why we have to limit ourselfs (this assumes of course
that it does not make the api totally horrible, but I don't think that
this is the case).

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

This is a good example and it shows a weakness. I do think it can be
adressed by e.g. forcing codecs (or fonts) to
DEBIAN_FRONTEND=noninteractive and only allow different settings for
the "do-anything" case.

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

If the user decides to get automated updates in the background then
this is fine. If the users wants updates in a interactive way, I think
we should not disallow debconf prompts for him, they may be good and
useful (or may not, but its hard to predict that).
 
> 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.

Agreed, non-interactive updates (or installs) should just work, but so
should the ones where the user wants debconf.

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

I will have to look into the code to see how to map it to PK. The
support in aptdaemon is relatively unobtrusive. There is no need for a
vte root window.

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

With debconf, the transaction may hang because it is waiting for input
from the user. Usually debconf questions are asked upfront, but it may
happen that they are asked during install (because the maintianer
scripts do odd things). I take from the above that this is still oK?

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

You use strong word here (I'm not a native speaker, so I may be
wrong). I don't think we "bully" you, we ask about features and we
offer help to implement them to make PK map to the deb world. The fact
that Sebastian went through the pain of doing aptdaemon shows IMO that
it is a important requirement.

How much it hurts the API remains to be seen while implementing it. So
far PK did not receive a warm reception in the deb world because it
does not map well to the requirements of the deb world.
 
> > 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

Again, some debconf questions are bad, but that does not mean we
should throw it out entirely. The admin/distros are still free to set
it to noninteractive. But I think the default tool to install packages
should be able to deal with all valid (deb) packages. And that
includes debconf questions. The fact that it does not currently is the
only reason we do not ship it by default (and that debian does not
have it at all). 
 
> > 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.

Thanks, I think we should continue the discussion ones there is some
code to show. I'm pretty happy with the discussion.

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

The Debian/Ubuntu packaging tools evolve as well :) There should be no
need for that anymore. While it still may be for some really old
package its a deprecated "feature" that a terminal needs to be
available (this was different in the past, but that is past now).

Cheers,
 Michael