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

[Otavio Salvador]

On Fri, Aug 21, 2015 at 2:45 PM, Khem Raj <raj.khem at gmail.com> wrote:
> On Fri, Aug 21, 2015 at 3:45 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> 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've talked to several significant users and they all "love" the idea of
>> this class and plan to adopt it ASAP over existing tools like
>> combo-layer. I therefore can't see much advantage of not merging the
>> class as people are going to use it regardless.
>>
>> 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). 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.
>>
>> So my objection is on record but that is likely about all I can do,
>> other than hope I'm overly paranoid...
>
> All points here are valid. We already see this with distro's which use
> layers verbatim e.g. angstrom
> I wish everyone derived their distros that way since that respects the
> layer boundaries, a good chunk of work
> there is still we send patches to layers to keep them up to date with
> changes in other layers and there still are patches
> pending since every layer maintainer doesnt respond in sam time frame,
> but this sort of facilities if added is just going to worsen that
> workload.
> I think amalgmation of layers start with use of combo-tool itself.
> This patch just takes it a step further. If we want to preserve
> the layer model's health we have to work towards respecting layer
> boundaries and I would even go a step further and suggest to
> discourage use of combo-tool or any sort of layer squashing.

I fully agree; in fact Poky itself is a bad example that I often have
to explain for vendors. People justify putting several layers together
in same repository saying that Poky does that and this is a
contradiction which we need to justify as Yocto Project promotes the
use of layers as one of most preeminent features but Poky does the
opposite ...

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750