[packagekit] viability of the current yum backend ?
Tim Lauridsen
tim.lauridsen at googlemail.com
Tue Jan 8 20:52:26 PST 2008
Robin Norwood 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?
>
> -RN
>
Looks fine to me. We can make a common python backend like the current
one, but using DBUS to send signals instead of the current printing to
STDOUT/STDERR and have some kind of event loop receiving DBUS signals
and call the appropriate methods to perform the actions. it will make it
easier to translate the current python backends.
Tim
More information about the PackageKit
mailing list