Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: bitbake-devel@lists.openembedded.org,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [bitbake-devel] Layer priorities influencing default version selection
Date: Thu, 25 Aug 2011 17:58:23 +0100	[thread overview]
Message-ID: <201108251758.23451.paul.eggleton@linux.intel.com> (raw)
In-Reply-To: <CAMKF1spSE=nuQ1LGOmub3XaH-z+6oJT+n5hC7LdKvdKeScLWNw@mail.gmail.com>

On Thursday 25 August 2011 16:56:28 you wrote:
> with layers we dont control policies of all the layers that may be used on
> top so fixing meta-oe does not solve problem completely and we can not ask
> for exclusive  recipes. People would want to override the recipes from other
> layers.

Generally, the less duplication we have across layers the better; if a 
maintainer is duplicating a recipe they should have a very good reason to do 
so. We can avoid some of this duplication by making it easier to figure out 
where the right place for recipes is and doing everything we can encourage 
people to get stuff merged there. I'm not convinced we are doing very well on 
either count yet, but I expect this will improve over time.

> bitbake could report the layer the recipe comes from which can make it
> evident or may be special command to inform the layer priorities. This will
> guide the users to diagnose the problems quickly and help developers to
> identify the issues faster. There could be a complete bill of recipes
> printed for a given target as well so if someone wants to check all
> the recipes that were built.

I had not considered BitBake itself reporting these, that might be useful 
especially in the case of errors (although the full path to the recipe is 
already reported during the build, so you should be able to tell in most cases 
from that if you need to). Outputting a specific report of parsed recipes and 
bbappends as part of the build also might be useful.

FYI, bitbake-layers exists as a separate utility to answer a lot of these 
kinds of questions, and recently has become a lot more powerful - I would 
strongly recommend everyone check it out and if it's not able to report what 
you want then please tell me and I'll try to make it do so. I already have a 
few ideas for future improvements there which I will hopefully get time to 
look into in the Yocto 1.2 cycle.

> In any case I agree that problems should be fixed. However this does
> not scale to all layers and we can not police all the layers and we should
> not. We should try to make it possible for people to glue layers together
> without  issues.

How does merely being able to alter the priorities help here though? I could 
begin to understand if you were asking for some way to blacklist individual 
recipes in individual layers, but moving the priority of an entire layer is 
likely to have much more of an effect than just obscuring a few errant recipes 
that you don't want.

We can't "police" all the layers, no. But if those who maintain that layer 
can't respond to and resolve problems then they shouldn't be maintainers or 
those layers can't be considered well-maintained. When you add a layer to your 
build you are placing some trust in the maintainer of that layer; it is up to 
the maintainer to make sure they don't abuse that trust.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



  reply	other threads:[~2011-08-25 17:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-02 11:26 Layer priorities influencing default version selection Paul Eggleton
2011-08-02 13:45 ` Richard Purdie
2011-08-02 13:52   ` Phil Blundell
2011-08-02 14:14     ` Chris Larson
2011-08-02 14:21       ` [bitbake-devel] " Paul Eggleton
2011-08-02 14:27         ` Chris Larson
2011-08-02 14:51           ` Paul Eggleton
2011-08-02 15:35       ` Khem Raj
2011-08-25 10:50         ` Paul Eggleton
2011-08-25 15:56           ` Khem Raj
2011-08-25 16:58             ` Paul Eggleton [this message]
2011-08-25 21:23               ` 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=201108251758.23451.paul.eggleton@linux.intel.com \
    --to=paul.eggleton@linux.intel.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /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