[packagekit] origin/forked-dbus-backend

[Richard Hughes]

Robin and I (99% him, 1% me) have been working on the
origin/forked-dbus-backend branch of PackageKit for the last couple of
days. I'll explain why all this code churn is important.

The non-dbus backend spawned scripts could be canceled by sending them a
unix signal, something that was easy to catch.

The existing dbus-backend model did a "client" asynchronous method on a
"server" (the backend dbus object) that then blocked until the
transaction completed.

This was fine, until we came to implement cancel. When a method call is
in progress is not pending, and can't be canceled, so my naive method of
canceling the pending call was never going to work. If we tried to call
the Cancel() method when the previous method was running then the bus
would queue it as that was the only sane thing to do.

So, back to the drawing board, we tried another approach.

The "client" does a synchronous method call on the backend, which then
forks and returns immediately. This solves a lot of the threading issues
in Lock() and Unlock(). The fork is pretty trivial to do in python and
C, and means we have one "master" thread handling the dbus bits, and
another internal thread for stuff like yum.

Now, before you panic, yum isn't multithread aware, which isn't an issue
as it's only being run in one thread.

I've asked rnorwood to merge in origin/forked-dbus-backend to master,
which hopefully he can do this weekend. This of course breaks apt2
(which I apologize for) but most of the code can be trivially converted
looking at the yum2 backend for reference.

When this is merged, we can get some serious testing done, and slow down
new development for a release as there are a few other good fixes to get
out there.

Richard.