[packagekit] [Q] How "GetDepends" connect with "get_depends"

[Richard Hughes]

On Tue, 2008-09-16 at 15:03 +0800, NZzi wrote:
> i wonder how "pkcon get-updates package" implement,
> so i browse packagekit code, but i know little
> about dbus, so after a whole day, i still can not
> understand how "GetDepends" connect with "get_depends".
> 
> i browse from pk-console.c:
> 
> } else if (strcmp (mode, "get-depends") == 0) {
> 	...
> 	ret = pk_console_get_depends (client, filters, value, &error);
> }
> 
> pk_console_get_depends()->pk_client_get_depends()->
> ret = dbus_g_proxy_call (client->priv->proxy, "GetDepends", error,...)

Correct, the pkcon program is just a front-end to the libpackagekit
library[4], which in turn is a front-end to the DBUS interface.

> i study some dbus docs, i konw dbus_g_proxy_call() call
> "GetDepends" method through proxy object(client->priv->proxy),
> but the "real" dependency-process function is get-depends() in
> yumBackend.py. and i found it's backend_get_depends()(in
> pk-backend-yum.c) invokd the get-depends().
> 
> but i don't know how dbus_g_proxy_call (client->priv->proxy, 
> "GetDepends"...)
> invoke backend_get_depends()(in pk-backend-yum.c)
> 
> can anyone give me some hints, thanks advance

No problem, thanks for taking the time to read the code. The actual
process is actually pretty simple:

The dbus server pk-engine.c takes the request for a TID [1] (transaction
ID) and creates a new PkTransaction object (and files it in a
PkTransactionList object. When this object is called with GetDepends,
(pk-transaction.c) takes the request[3], and saves all the parameters,
checks permissions and that sort of thing.

When PkTransactionList detects that nothing else is running, the new
PkTransaction is "run" which means that it takes control of the single
PkBackend instance and the backend is run and waits for that transaction
to finish.

Now, that explains how the daemon schedules requests (as the backend can
only ever do one thing at a time) but doesn't explain how the yum code
is actually run.

In the /etc/PackageKit/PackageKit.conf file you'll have a DefaultBackend
option, which will point to yum. When the daemon starts up, it dlopens a
shared object file for whichever the default backend is, in this case
you can see the code in pk-backend-yum.c

This code maps a vtable (a table of functions) to the PkBackend
instance, so that when the functions in PkBackend are called, these are
mapped to the functions in pk-backend-yum.c

These functions are responsible for launching the yum executable
yumBackend.py (using pk-backend-spawn.c, which in turn uses pk-spawn.c)
and watches the standard out for replies, and then when it's done it
kills the program. [2]

In the new dispatcher [5], it gets a little bit more complicated as the
spawned executable is not closed down after every transaction, and
instead can stay running in the backend for a few seconds. This makes
using the GUI a lot snappier, as yum isn't being created and destroyed
all the time.

Actually, when reading that back, it doesn't seem so simple anymore!

Feel free to ask about any of that stuff I've explained badly. I
probably need to add something like this in the code anyway.

Richard.

[1] http://www.packagekit.org/gtk-doc/introduction-ideas-transactions.html
[2] http://www.packagekit.org/gtk-doc/backend-spawn.html
[3] http://www.packagekit.org/gtk-doc/Transaction.html
[4] http://www.packagekit.org/gtk-doc/PkClient.html
[5] http://article.gmane.org/gmane.comp.freedesktop.packagekit/3237