[OE-core] [RFC PATCH 0/1] QA check for defined packages

[Richard Purdie]

On Wed, 2011-10-12 at 10:43 -0700, Joshua Lock wrote:
> On 10/12/2011 05:37 AM, Richard Purdie wrote:
> > On Tue, 2011-10-11 at 15:29 -0700, Joshua Lock wrote:
> >> I'm looking for some comments on this WIP patch.
> >>
> >> The reason I've added this is because the hob GUI requires us to offer much
> >> more reliable metadata - we show the user available packages, as defined by
> >> each recipe, to add to their image. Should a recipe define a package and yet
> >> not actually create it and the user has included that in their image we cause
> >> errors at build time.
> >>
> >> However whilst the idea seems sound enough, there are some caveats - running
> >> a world build with this patch I see failures fairly early on at least a few
> >> of which I'd expect we'll need to special-case:
> >> * eglibc-local
> >> * linux-yocto
> >> * linux-libc-headers
> >> * gcc-runtime
> >>
> >> Thoughts?
> > 
> > I think we probably do need to cleanup some of that data.
> > 
> > I have some thoughts about where we're at with hob and this is probably
> > as good a time as any to share them.
> > 
> > Effectively the problem is that there is a large body of data we only
> > compute during the build process. This includes what the exact runtime
> > dependencies of packages are, which packages exactly are generated
> > (PACKAGES_DYNAMIC), what the size of the packages are, how long they
> > take to build and so on. Some things we can fix, some things we can hack
> > around but at the end of the day there are some things we just plain
> > can't change.
> > 
> > I'm beginning to think we need to have two phases of control of the
> > system:
> > 
> > a) The build phase
> > 
> > This is the step that generates the package feeds.
> > 
> > b) The image construction phase
> > 
> > This is the step that takes the package feed data and turns it into an
> > image.
> 
> I actually think this is a neat idea, in fact we have the beginnings of
> a Gtk+ GUI to create images from a package feed which Rob Bradford
> worked on some 3 years or so ago - puccho. It's no doubt bit-rotten but
> may be worth a look.
> 
> I think we can reuse pieces from puccho and hob to create a GUI per this
> high-level design and I think we'd be much better off for it.
> 
> > Obviously, you can skip to b) if you already have a package feed.
> 
> a), right? Indeed I expect that this will be more in line with certain
> proposed use cases.

No, you'd skip the package feed generation and just end up using it so
skip a) and start from b).

> > So we'd be talking about two UI's that could effectively hand off to
> > each other and share a "build in progress" feedback to the user system.
> > The image construction dialog would have a "Missing Packages? Build them
> > here" type switch. This would mean the build system can continue on at
> > what it does best yet the UI can let the users do what they want to do,
> > particularly on a prebuilt package feed.
> 
> I like it. I think we had to "write one to throw away" to realise quite
> how much data we're missing up front but I support the proposed design.

I'd not say thrown away. We've moved a lot of the code forward and
significant pieces would get reused...

Cheers,

Richard