[OE-core] [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES

[Martin Jansa]

On Wed, Aug 06, 2014 at 01:48:31PM +0200, Martin Jansa wrote:
> On Mon, Jul 28, 2014 at 02:18:30PM +0100, Richard Purdie wrote:
> > On Thu, 2014-07-24 at 17:22 +0200, Martin Jansa wrote:
> > > On Thu, Jul 24, 2014 at 02:52:45PM +0100, Burton, Ross wrote:
> > > > On 24 July 2014 14:42, Martin Jansa <martin.jansa at gmail.com> wrote:
> > > > > +REQUIRED_DISTRO_FEATURES = "x11"
> > > > 
> > > > Now I'm wondering why this is the solution.
> > > > 
> > > > If you attempt to build e.g. gnome-desktop explicitly without the x11
> > > > distro feature you understandably get an error message, because
> > > > gnome-desktop depends on libx11 which sanity checks the distro
> > > > features.  This seems correct.
> > > > 
> > > > Presumably you're problem is that you're running world builds and
> > > > they're producing errors on gnome-desktop because they can't satisfy a
> > > > dependency on libx11.  It seems that bubbling up the
> > > > REQUIRED_DISTRO_FEATURES tests isn't the right thing to do here - why
> > > > can't SkipPackage be handled specially, so if you do bitbake -k world
> > > > and libx11 emits SkipPackage, anything that has unsatisfiable
> > > > dependencies because of this is also skipped?
> > > 
> > > We discussed this many months ago and IIRC the conclusion was that user
> > > should explicitly say that he wants to skip the recipes which depend on
> > > something skipped (so that he is aware of what he is missing).
> > > 
> > > At that time there wasn't REQUIRED_DISTRO_FEATURES support, so I've
> > > created huge list of PNBLACKLISTs to blacklist everything not available
> > > in our setup - so I can do world builds without ERRORs at the beginning.
> > > 
> > > REQUIRED_DISTRO_FEATURES seems to me like reasonable compromise, that's
> > > why I've sent this patchset to replace small part of my huge blacklist.
> > > 
> > > This is the list:
> > > https://github.com/openwebos/meta-webos/blob/master/conf/distro/include/webos-recipe-blacklist-world.inc
> > > 
> > > If someone has time to improve SkipPackage and we really want to skip
> > > all depending packages, I would be glad to test such patch (because it
> > > allows to easily drop all those blacklists for "depends-on-broken"
> > > components)
> > 
> > The question here is whether we want a system which calculates what it
> > thinks is right or that we declare it.
> > 
> > The risk is that if SkipPackage (now known as SkipRecipe) were to
> > automatically "spread", you could in theory break the toolchain, have
> > nothing buildable and "bitbake world" would return success.
> > 
> > Effectively the -k option to bitbake already does the SkipPackage
> > "spread" idea since bitbake just removes dependencies until it works. If
> > does that in a fairly verbose way but it does so deliberately so you can
> > see what is going on.
> > 
> > The alternative is to declare what a given recipe supports and then we
> > can know whether it should be skipped or not under a given circumstance.
> > 
> > Personally, I'm leaning towards a more declarative approach where we
> > specify what should and shouldn't be expected to work. I'm open to
> > discussion on it though...
> 
> I agree with more declarative approach.
> 
> I don't mind maintaining PNBLACKLIST e.g. for components depending on
> something we decided to blacklist ourselves in distro config.
> 
> But for components like this, where we really know that they won't work
> without X11 in DISTRO_FEATURES, I think bitbake should skip them
> automatically (thanks to REQUIRED_DISTRO_FEATURES). It already
> automatically skips all recipes in xorg-lib directory, why it shouldn't
> skip other recipes living somewhere else?

Can we make some decision now?

> > Cheers,
> > 
> > Richard
> > 
> > 
> > 
> > 
> 
> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com



-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20141030/ab21c4cd/attachment-0002.sig>