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

[NZzi]

NZzi wrote:
> Richard Hughes wrote:
>> 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.
> 
> 
> thanks very much for your detail explanations.
> 
> sorry, i know nothing about glib and dbus, so can you
> explain more about the process of "daemon schedules requests".
> 
> after frontend(client) send "GetDepends" method call
> request through proxy object(transaction interface),
> how packagekitd react in source code? i only know
> packagekitd go into glib loop, after create engine,
> and etc.
> 
> After getting the "GetDepends" method call request,
> how packagekitd call backend->desc->get_depends?


BTW:

i found pk_transaction_get_depends() set role:

pk_transaction_set_role (transaction, PK_ROLE_ENUM_GET_DEPENDS);

but i did not found anyone call pk_transaction_get_depends()


> 
> 
>>
>> 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
> 
> 
> how "GetDepends" map to backend_get_depends() in PkBackendDesc.
> 
> i read following doc:
> 
> http://www.packagekit.org/gtk-doc/backends-spawn-methods.html
> 
> which said "Get Depends" is mapped from the helper to either
> command line programs or a dispatcher in the spawn helper, but
> i browse all codes, still cannot understand how the map
> implemented.
> 
> 
>>
>> 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
>>
>>
>> _______________________________________________
>> PackageKit mailing list
>> PackageKit at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/packagekit
>>
> 
>