On Fri, Aug 21, 2015 at 7:45 AM, Richard Purdie <richard.pur...@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.eggle...@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...
I fully support your objection and I also nervous about this one. Often vendors want to narrow their responsibility and focus so this class opens the door for this to be done officially. :-( -- 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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core