[packagekit] OM-Installer is going to release

[Richard Hughes]

On Tue, 2008-08-12 at 18:01 +0800, Tick Chen wrote:
> 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. 

Cool. What do you want the branch name to be?

> > 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.

Please.

> > >   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. :-) 

Any obvious memory leaks you've noticed? Before 0.3.0 (soon!) I'll be
really valgrinding things hard, but I can only do the dummy and yum
backends.

> > 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. 

Hmm, sounds very odd.

> 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

Do you mean the value of PkBackend? That shouldn't change as it's
reused. Do you mean the value of Pktransaction? In which case, are you
debugging using a printf in pk_transaction_package_cb?

Richard.