[OE-core] [RFC PATCH 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer

Patrick Ohly patrick.ohly at intel.com
Fri Aug 21 11:59:24 UTC 2015


On Fri, 2015-08-21 at 11:45 +0100, Richard Purdie wrote:
> On Wed, 2015-08-19 at 14:34 +0100, Paul Eggleton wrote:
> > Allow restricting recipes brought from a layer to a specified list. This
> > is similar in operation to blacklist.bbclass, but instead specifies a
> > per-layer whitelist of recipes (matched by BPN) that are able to be
> > built from the layer - anything else is skipped. This is potentially
> > useful where you want to bring in a select set of recipes from a larger
> > layer e.g. meta-oe.
> > 
> > Implements [YOCTO #8150].
> > 
> > Signed-off-by: Paul Eggleton <paul.eggleton at linux.intel.com>
> > ---
> >  meta/classes/whitelist.bbclass | 28 ++++++++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >  create mode 100644 meta/classes/whitelist.bbclass
> 
> I should go on record as having some pretty strong reservations about
> this from a philosophical standpoint.
> 
> Why? I think its going to encourage behaviours which will result in a
> decrease in layer quality, particularly for meta-oe.
> 
> Taking a simple example, today if someone breaks parsing in meta-oe, its
> quickly known about and multiple people can see and resolve the issue.
> Once people start using this class, many users will simply never
> see/care about parsing breakage in less maintained parts of the layer.
> 
> I appreciate Martin will likely notice, however this shouldn't Martin's
> sole responsibility.
> 
> Since people's focus will be on to narrow parts of the layer, we'll
> start to see islands which are well maintained/used and islands which
> are not. Worse, just looking at the layer, we won't be able to tell
> which is which.
> 
> I'm nervous about anything which pushes responsibility onto already
> overloaded maintainers and encourages behaviour which is a net loss on
> "quality".

I understand that concern. I don't know whether there are currently
users who take the full meta-oe and would stop doing that once this
class gets added. But I know that the inverse is also going to happen:
not using meta-oe at all, starting to use a subset of it with this
whitelist.bbclass. Whether that's a net gain or loss overall I have no
idea.

> Speaking of it, combo-layer was designed to be an alternative way of
> dealing with these issues (more pain to use but causing less of a
> quality impact).

I disagree here. When using combo-layer with filter to pick "desired" or
"supported" recipes, you have the exact same effect as with whitelisting
(only those recipes get tested).

Without filter we have indeed the situation of someone taking the entire
meta-oe and activating it, but that's independent of using combo-layer
or not.

> Sadly, whilst it has seen some improvements, it still
> doesn't handle every operation it would need to make it work for some
> users and isn't widely adopted. I simply don't have the time to go and
> push it forward.

I'm not sure what improvements you have in mind here. The "filter"
mechanism certainly could be enhanced (filtering out a recipe and
adding it later does not work), but that's conceptually the same as
whitelisting.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.






More information about the Openembedded-core mailing list