[packagekit] OM-Installer is going to release

[Tick Chen]

Hi Hughes,  
On Fri, Aug 08, 2008 at 09:28:40AM +0100, Richard Hughes wrote:
> On Fri, 2008-08-08 at 14:02 +0800, Tick Chen wrote:
<skip>
> 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.
> 
Yes, I'd love to move all the stuff back to mainstream. 
> 
> I think that would be a good idea -- then I can keep the binding up to
> date if we ever change API again.
> 

Okay, then I will move those part into packagekit.
> >   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.
> 
Yes, 
Now there are few memory leaks. Still have some, but much better than it
was before. :-) 
I do not use PkExtra.
> 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.
> 
Oh. It's very strange. When I call many search group in the same time,
Packagekit may occisaionally call the call back functions of different 
requests at the same time.  Libopkg may have different racing
conditions, (on reference count). I put lock for the reference count
issues. That largely improve the stability. However I still get
one report of calling wrong call back functions. (Since I lock opkg
stuff, it's seems a pure packagekit issue.) Therefore, I have to find it
out later. 

The status I observed:
 A: my client process
 P: packagekitd 

A: query search group unknown with PkBackend 0x10
   query search group repos   with PkBackend 0x20
   query search updates       with PkBackend 0x30

P: returns result of search group unknown with PkBackend 0x10 and 0x20
   returns result of updates with PkBackend 0x30
   never returns result of group repos

Cheers, 
Tick
> Cheers for the feedback, I appreciate it.
> 
> Richard.
> 
> 
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.openmoko.org/pipermail/devel/attachments/20080812/483f56a4/attachment.pgp