[packagekit] viability of the current yum backend ?

[Tim Lauridsen]

James Bowes wrote:
> On Jan 8, 2008 12:05 PM, Robin Norwood <rnorwood at redhat.com> wrote:
>> Richard Hughes <hughsient at gmail.com> writes:
>>
>>> On Thu, 2008-01-03 at 08:22 +0100, Tim Lauridsen wrote:
>>>> You are right, it sucks to setup yum each time we do some kind of
>>>> packagekit backend action, the way to do it is have some kind of
>>>> persistence yum object loaded one time and let the the helper script
>>>> call it over DBUS.
>>> Agreed.
>> So how does this work, exactly?
>>
>> Something like:
>>
>>    C Backend                          Python Backend
>>        |
>>      Start
>>        |
>>  Start python backend --(exec and fork?)--Start
>>        |                                    |
>>        |                                    |
>>   Run an action ----------DBUS--------> (Do Stuff)
>>        |                                    |
>>  Receive results <--------DBUS--------- Send status update
>>        |                                    |
>>      (etc)                                (etc)
>>        |                                    |
>>     Keep alive -----------DBUS----------->  OK
>>        |                                    |
>>      (etc)                                (etc)
>>        |                                    |
>>     "Die now" ------------DBUS----------->  OK (clean up and die)
>>        |                                    |
>>      Exit                                  Exit
>>
>>
>> (Sorry for the diagram)
>>
>> Where the current backend lifecycle remains pretty much the same - It
>> starts upon receiving the first action from the frontend, and persists
>> for a certain amount of time after the last action in case another
>> action is on the way.  Except now, isntead of spawning a process for
>> each action, and waiting for the results on STDOUT/STDERR, it spawns a
>> single process, and talks to it over DBUS.  The python process sticks
>> around until it receives a "die now" from the backend, or it stops
>> getting 'keep alive' messages (in case the backend crashes).
>>
>> Is this about what you're thinking?
> 
> So if that's the case then that python daemon is going to have to be
> threaded to handle any actions that can be run in parallel, right?
> Maybe not for the yum backend, as it really can't do anything in
> parallel, and we could have packagekitd be aware of if it has a
> request out already, and hold off until that request returns before
> sending a new one.
> 
> We could also keep with the subprocess spawning, but have the
> communication be two way over pipes, so that after you have
> initialized one subprocess you could keep using it after it served the
> first request. This would also allow for the current model of multiple
> spawned subprocesses at the same time in backends that support
> parallel actions.
> 

I agree with that parallel actions don't make much sense to the yum 
backend, it have to perform actions one at a time. All the yum action 
has to perfomed py the same subprocess, because the sqlite databases 
used by yum is not thread safe.

but some kind of DBUS event handler daemon and a sub process doing the 
real actions and some interface to do communicate over pipes, might be a 
way to go.

Tim