From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES
Date: Thu, 30 Oct 2014 14:20:53 +0100 [thread overview]
Message-ID: <20141030132053.GF15148@jama> (raw)
In-Reply-To: <20140806114831.GG14848@jama>
[-- Attachment #1: Type: text/plain, Size: 3971 bytes --]
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@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@gmail.com
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
next prev parent reply other threads:[~2014-10-30 13:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-24 13:42 [PATCH 1/4] xorg-app: add x11 to required DISTRO_FEATURES and cleanup dependencies Martin Jansa
2014-07-24 13:42 ` [PATCH 2/4] recipes: add x11 to required DISTRO_FEATURES Martin Jansa
2014-07-24 13:52 ` Burton, Ross
2014-07-24 15:22 ` Martin Jansa
2014-07-28 13:18 ` Richard Purdie
2014-08-06 11:48 ` Martin Jansa
2014-10-30 13:20 ` Martin Jansa [this message]
2014-10-30 13:28 ` Richard Purdie
2014-10-30 14:18 ` Koen Kooi
2014-11-11 17:13 ` Martin Jansa
2014-12-10 14:18 ` [PATCHv2 1/4] xorg-app: add x11 to required DISTRO_FEATURES and cleanup dependencies Martin Jansa
2014-12-10 14:18 ` [PATCHv2 2/4] recipes: add x11 to required DISTRO_FEATURES Martin Jansa
2015-01-20 21:17 ` Burton, Ross
2015-01-21 12:27 ` Martin Jansa
2014-12-10 14:18 ` [PATCHv2 3/4] xorg-driver: " Martin Jansa
2015-01-20 21:17 ` Burton, Ross
2015-01-22 16:34 ` Martin Jansa
2015-01-23 12:46 ` Burton, Ross
2014-12-10 14:18 ` [PATCHv2 4/4] recipes-qt: " Martin Jansa
2015-01-20 21:19 ` Burton, Ross
2015-01-22 16:34 ` Martin Jansa
2015-01-18 17:06 ` [PATCHv2 1/4] xorg-app: add x11 to required DISTRO_FEATURES and cleanup dependencies Martin Jansa
2015-01-20 20:12 ` Burton, Ross
2014-07-24 13:42 ` [PATCH 3/4] xorg-driver: add x11 to required DISTRO_FEATURES Martin Jansa
2014-07-24 13:47 ` Burton, Ross
2014-07-24 13:42 ` [PATCH 4/4] recipes-qt: " Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141030132053.GF15148@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox