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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
