From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dan.rpsys.net ([93.97.175.187]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1RE4Pb-00020g-S0 for openembedded-core@lists.openembedded.org; Wed, 12 Oct 2011 21:24:20 +0200 Received: from localhost (dan.rpsys.net [127.0.0.1]) by dan.rpsys.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id p9CJPB5i020165 for ; Wed, 12 Oct 2011 20:25:12 +0100 X-Virus-Scanned: Debian amavisd-new at dan.rpsys.net Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mF3iXlr9pVAy for ; Wed, 12 Oct 2011 20:25:11 +0100 (BST) Received: from [192.168.1.66] (tim [93.97.173.237]) (authenticated bits=0) by dan.rpsys.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id p9CJP8ZM020162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Oct 2011 20:25:10 +0100 From: Richard Purdie To: Patches and discussions about the oe-core layer Date: Wed, 12 Oct 2011 20:18:25 +0100 In-Reply-To: <4E95D1C1.2020000@linux.intel.com> References: <1318423059.23801.151.camel@ted> <4E95D1C1.2020000@linux.intel.com> X-Mailer: Evolution 3.1.91- Message-ID: <1318447114.23801.178.camel@ted> Mime-Version: 1.0 Subject: Re: [RFC PATCH 0/1] QA check for defined packages X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 19:24:20 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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