[packagekit] Canceling background transaction

[Scott Reeves]

>>> On 3/14/2011 at 10:09 AM, Richard Hughes <hughsient at gmail.com> wrote: 
> A proposal:
> 
> packagekitd has one task running thanks to a session service
> automatically getting the updates list:
> 
> [running] get-updates (non-interactive, background)
> 
> and then the user fires off a search, so now we have:
> 
> [running] get-updates (non-interactive, background)
> [waiting] search-name (interactive, foreground)
> 
> The last thing we want to is make the user wait for a task that can
> easily be rescheduled in a few minutes to no ill effect.
> 
> I'm proposing we cancel non-interactive tasks if an interactive task
> is present.

That would be really nice. I have hit this issue before and wanted to jump to the front of the queue.

> It'll be up to the session program to reschedule the
> non-interactive task when convenient. This would mean special casing
> the ErrorCode of CANCELLED_PRIORITY (better names welcomed) and just
> rescheduling the action straight away. In the case of packagekit-glib,
> this would be automatic.
> 
> Comments?

What about extending this idea to include the SuggestDaemonQuit dbus method. The use case is that when someone tries to manually use the native package management tool (in our case via libzypp) we make this call and it works great if packagekitd is in idle mode. However we still get semi frequent complaints when a user tries a manual native command and a background task is using the packagekitd daemon so it won't quit. Essentially the same logical scenario as above - we still lock out the user for a background task that could be run later.
Could SuggestDaemonQuit check for only non-interactive transactions running and if so cancel them and exit. Then also instead of having the session program immediately reschedule the action, delay a short while and then reschedule (ie a couple minutes to give the user a chance to finish their manual work).