[packagekit] New dbus backends

[Richard Hughes]

Right, if some of you have been watching the commit history, you may
have noticed a new dbus backend type. This is designed as a little
mini-daemon that exists as a separate process to packagekitd, and is
created and destroyed by packagekit. It's only useful for the spawned
python/perl backend types (yum and conary) and the old spawned type
isn't going away anytime soon. Worry not.

This means we have (for the dbus case):

client -> daemon -> helper_dbus
helper_dbus -> daemon -> client

which seems a lot of IPC, but is needed for the backend objects to be
abstract. DBUS also seems to be a lot quicker than the spawned case,
where we were using stdout and then decoding it in the daemon. Using
DBUS also lets us keep the object around for multiple transactions which
is great from a speed point of view and should put us on par with pirut
and the ubuntu update-viewer.

Now, some people may want to keep the daemon around for a few minutes,
but want to use native tools such as apt-get or yum when the daemon is
loaded. For this reason there are Unlock and Lock methods on the
backend. For instance:

(packagekitd loads}
org.freedesktop.PackageKitYum is created as a new python process
org.freedesktop.PackageKitYum.Init()
(user searches by name)
org.freedesktop.PackageKitYum.Lock()
org.freedesktop.PackageKitYum.SearchName("foo", "gui")
::org.freedesktop.PackageKitYum.Package(INSTALLED, "GNOME foobar")
::org.freedesktop.PackageKitYum.Finished(SUCCESS)
org.freedesktop.PackageKitYum.Unlock()
(after a minute or so the daemon times out)
org.freedesktop.PackageKitYum.Exit()
(the daemon quits)

This means that daemons that have to load stuff like python only have to
do it once, but the native tools still can run when unlocked. If
something like apt needs to be locked even when loaded, then the Lock()
and Unlock() methods can be no-ops, and the database lock can be got in
Init() and released in Exit(), although then we'll get winging users as
the native tools won't work for a minute or two.

I know robin has added some common dbus python stuff to git recently,
and I didn't want to work cross-purposes from him. I know I need to
explain more than commit, and this is what I'm trying to do :-)

You can see the basics at backends/test/helpers/PackageKitDbusTest.py
although this needs hooking up to robins stuff before it's terribly
useful. As a python novice myself, I'll be needing much help with this.

For the time being, the traditional spawned backends (conary and yum)
should continue to work, although at a tiny increased performance as we
are not doing the dlload each time.

Richard.