Op 30 okt. 2014, om 14:28 heeft Richard Purdie <richard.pur...@linuxfoundation.org> het volgende geschreven:
> On Thu, 2014-10-30 at 14:20 +0100, Martin Jansa wrote: >> 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.ja...@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? > > Well, I think there was an implied outcome of this: > > a) We don't want to automatically do things, we want something > declarative > > b) We therefore need to go and add REQUIRED_DISTRO_FEATURES = "x11" to > some further places. > > As such, I'll take patches. > > Was that what other people understood? That's how I read it and FWIW, I agree. regards, Koen -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
