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.
> 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.
Regards,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
