[packagekit] OM-Installer is going to release

[Richard Hughes]

On Fri, 2008-08-08 at 14:02 +0800, Tick Chen wrote:
>   I am very glad to say that the OM-Installer (Assassin as the internal
> project name you know before) in which talk with packagekit through DBus, 
> is going to release at today 2008.8.8 with Om2008.8 release. 
> I want to praise your amazing project and thank to Thomas great work. 
> Thank you.

Rock on! Thanks.

>   In order to prepare release, I stop pulling from upstream since
> 813fa8cfb139246cf180d52895b52b28616ae2f5 At 2008, Jun 6th.

Would you like an upstream branch to work on? That's what I've done for
Suse and I'll probably do the same for Fedora.

>  In this days
> I had created some patches and put them into our own build system. Some of them
> are just for our own features. For general issues such memory leaks, I
> just cherry-picked to the upstream. 

I see, cool.

>   In OM-Installer we create a set of functions that talk to packagekitd
> through dbus via EDBus, and I think this park actually can be a bridge
> that introduce Packagekit to ecore_main_loop. For libpackagekit use the
> event system of GMainLoop. If you want, I can divide this part into
> library to packagekit for EFL support. 

I think that would be a good idea -- then I can keep the binding up to
date if we ever change API again.

>   I had chat with your about repository ping issues, I didn't put them
> into upstream, because of I don't think it is elegant to put them on
> pk_engine_get_network_state. I believe you will come up a better place
> to put this feature. 

Yes, I need to think about this some more. What's your use cases for
this -- is it "check we can contact the repos" -- and what's the user
interaction for dealing with failure?

>   The attaches file are patches and bb file in our build system (OpenEmbedded). 

You can put the bb file into contrib/ if you like -- there's already a
fedora spec file there.

> Recently with largly testing, I found that packagekit may (seldom) call the wrong
> callback function after a large amount request. I am not knowing if this
> is an known issues nor a solved issues. Except this issue, packagekit
> runs perfectly on our Neo.  :-)

Cool. Did you profile the daemon? I've done much performance testing,
but not much memory testing. I would imagine it's pretty lightweight,
unless you start using the PkExtra database.

I guess you're trying to mitigate the race issue with
opkg_thread_{un}lock -- could you describe the problem in more detail
please? It's quite possible there is a race, but when identified we can
add a test for this in our make check tests so it doesn't ever happen
again.

Cheers for the feedback, I appreciate it.

Richard.