[OE-core] [PATCH 2/2] packagegroup-core-x11: split machine specific parts to separate recipe packagegroup-core-x11-server
Richard Purdie
richard.purdie at linuxfoundation.org
Thu Sep 6 23:37:10 UTC 2012
On Fri, 2012-09-07 at 01:34 +0200, Martin Jansa wrote:
> On Fri, Sep 07, 2012 at 12:29:59AM +0100, Richard Purdie wrote:
> > On Tue, 2012-09-04 at 22:58 +0200, Martin Jansa wrote:
> > > * add new packagegroup-core-x11-server to SIGGEN_EXCLUDERECIPES_ABISAFE,
> > > so that recipes depending on it are not rebuilt after every machine
> > > swtich
> > > * allows to remove task-x11-server and task-x11 from meta-oe without
> > > loosing any functionality
> > > * be carefull with default XSERVER value which does not have
> > > xf86-input-mouse and xf86-input-keyboard)
> > > * VIRTUAL-RUNTIME_xserver_common which defaults to x11-common in oe-core
> > > and xserver-common in meta-oe's task-x11
> > >
> > > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > > ---
> > > meta/conf/layer.conf | 1 +
> > > .../packagegroups/packagegroup-core-x11-xserver.bb | 24 ++++++++++++++++++++++
> > > .../packagegroups/packagegroup-core-x11.bb | 16 ++-------------
> > > 3 files changed, 27 insertions(+), 14 deletions(-)
> > > create mode 100644 meta/recipes-graphics/packagegroups/packagegroup-core-x11-xserver.bb
> >
> > This sneaked in with a load of other patches. I never meant to merge
> > this as I consider it broken.
> >
> > Task packages are cheap and having them being machine specific imposes
> > little overhead. Splitting this into two just increases the parsing
> > overhead through the number of recipes and doesn't do much else since
> > there are still machine specific packages involved, all dependencies
> > still get built etc. so I really don't see the point of the added
> > complexity.
>
> Yes task-* are cheap but if such recipe is in RDEPENDS of some other
> more expensive recipe then it's better when it's excluded from sstate.
Which expensive recipes RDEPEND on task/packagegroup recipes?
Cheers,
Richard
More information about the Openembedded-core
mailing list