[packagekit] making status mandatory

[Richard Hughes]

A few days ago I merged into git a patch that makes status mandatory: 

*** WARNING ***
Backends should send status <value> signals to update the UI!
If you are:
* Calling out to external tools, the compiled backend should call pk_backend_change_status() manually.
* Using a scripted backend with dumb commands then this should be set at the start of the runtime call
   - see helpers/yumBackend.py:self.status()
* Using a scripted backend with clever commands then a   callback should use map values into status enums
   - see helpers/yumBackend.py:self.state_actions
[pk_backend_finished] pk-backend.c:1093 (22:35:25):      GUI will remain unchanged!

If your backend does not emit status for the lifetime of the transaction
then the daemon will warn you with this big fat notice.

Background:

"status" is needed to know what icon to show in PkProgress and also in
the tray icon. It seems many of the backends do not update the UI status
even once, which is a bad thing. I've fixed up the yum backend to do
calls to self.status(STATUS_QUERY) for search operations,
self.status(STATUS_INFO) for information getting and then we can add
other enums as needed.

We can't just do this in the compiled backend as tools may have to start
new threads or processes (or even spawn stuff like python), parse config
files and setup environments which will take a few seconds to setup.

status is basically a way of telling packagekit "this is the status of
the transaction" where status could be DOWNLOAD, INSTALL, QUERY,
DEPSOLVE etc and allows us to feed this back to the user with icons and
tooltips. Status never corresponds to individual packages, only the
transaction as a whole.

Note, if you emit "package downloading foo;0.10;i386;misc" then you
don't also have to do "status download", as the daemon is smart enough
to work out what it should do.

Yell if none of this makes sense and I can make it clearer. The only
status enums I think we need to add are STATUS_DEPSOLVING - yell if
there are any more.

Thanks,

Richard.