[oe] Merging openmoko into OE

[Richard Purdie]

On Mon, 2007-03-05 at 15:35 +0100, Harald Welte wrote:
> On Mon, Mar 05, 2007 at 02:23:19PM +0000, Richard Purdie wrote:
> > > > As far as the buildsystem is addressed, there are some distinct features
> > > > which we're lacking currently.  I have hired an experienced python
> > > > hacker to add those things properly to bitbake and then talk to you guys
> > > > about how this code can be merged.
> > 
> > Could the experienced python hacker at least talk to the active bitbake
> > developers before they go too far with this as it might be we can help
> > each other and save time. I'd hate to see two implementations
> > duplicating effort. I'm also a bit upset we're only learning of this
> > through a forwarded email and were not approached directly.
> 
> IIRC, mickey said he wold ping you, but maybe that just got lost before
> he went on holidays.  It has been an awfully busy time.

Mickey mentioned something very briefly about a problem but he was in a
hurry and I'd actually misunderstood the problem looking at this :/. I
also thought he'd found a solution that worked for now meaning more time
could be spent solving it properly.

In future, please do send a mail to the bitbake development list if
there are problems like this.  

> And please don't be too upset.  The time loss will be ours, i.e. a
> monetary loss.  We're committed to do whatever changes/merging required
> even after our initial 1.6.x implementation.

Fair enough, I understand the problem.

> > FWIW, bitbake is shaping up for a stable 1.8.x series now.
> 
> yes, we've noticed that.

Even if you don't switch to using 1.8.x, it would be good if you did
have time to test it and let us known what (if any :) issues you have
with it. I'm about to send something to the lists requesting testing
before we release 1.8.0.

> > > > 3) find a cleaner way for the deploy/images directory.  There need to be
> > > >    per-release symlinks so that an automatized flashing tool can always
> > > >    assume that the current kernel for one release/snapshot/branch has a
> > > >    fixed name (can be symlinks). 
> > > 
> > > Ok, that's not too hard, I recall Richard making a start with that for the zaurus machines.
> > 
> > Its not Zaurus specific and I have this working in poky for all its
> > images/kernels. Its relatively simple to do.
> 
> is that available as bbclass or how do we activate that feature?

It should just work but I suspect the changes haven't all been merged
from poky -> OE.dev though (just due to lack of time). I'll look into
it.

> > > > 5) find a way how to completely clean up a package, including all
> > > 
> > > s/package/recipe/
> > > 
> > > >    related download cache, bitbake rule cache, .ipk's and/or 'images'
> > > >    that it created
> > > 
> > > Holger and I discussed something like that for the packaged-staging project, but we didn't
> > > come up with a clean way to present it to the user. That was last year, and I'm sure
> > > others can come up with something.
> > 
> > This needs packaged staging which is quite an effort. Please do discuss
> > this before implementation as we've tried things before and know roughly
> > how this can work.
> 
> ok, will do.  this is less important at the moment.

This is a long term project aim for OpenEmbedded (and me personally)
since it doesn't just solve this problem but solves a number of others
too. It would be great to see it developed.

> > > > 7) related: reimplement ipkg backend to use some indexed database. It's
> > > >    just too slow
> > 
> > Are we talking about on device use or use during image generation? On
> > device is tricky but there are simple ways of speeding up image
> > generation that just need implementation.
> 
> image generation is not an issue at all.  
> 
> We're talking about on-device use which is way too slow for our needs,
> especially considering the number of packages and that we'll have a GUI
> application in front/on top, in addition to that.
> 
> If there are existing plans/ideas in this area, or somebody with some
> ipkg background has a good proposal and wants to implement it as paid
> contractor, this would be the time to talk about it.

I think lots of people, me included have looked at the ipkg code and
wanted to see it rewritten with something like a sqlite backend rather
than parsing its ascii files all the time.

Cheers,

Richard