[oe] bitbake does not fail when QA issues encountered

[Frans Meulenbroeks]

2011/1/27 Thomas Zimmermann <ml at vdm-design.de>:
> On Wednesday 26 January 2011 16:27:43 Tom Rini wrote:
>> I believe, from talking with Chris Larson about this before, in 1.8.x
>> the error wasn't being populated upwards, but that got fixed.  At heart
>> the problem is that QA errors aren't throwing a "kill the build" type
>> error.  This should be changeable (and would cause 1.8.x to fail too, if
>> someone backported this change to a 1.8.x using OE) to insane.bbclass.
>
> I don't think that a QA error should "kill the build" because then no build
> from scratch would be possible.
> We have a QA error in coreutils-native because it doesn't inherit gettext. But
> adding this inherit would result in a dependencie loop.
>
> So if a QA error would stop build we would need something for those
> situations.
>
> And additionally i think that most QA errors aren't fatal because most of them
> are for non-standard .desktop files.

If it is not a fatal it should probably be given as a warning
(especially the non-std .desktop things)
If corutils-native has a problem becuase it does not inherit gettext,
then maybe (if possible) it should be added or alternately if this is
not a problem it definitely should not be an error but a warning.

For me an error indicates something is broken and needs fixing.
Reverting that: if a condition does not break things it is not an
error (and yes, I know this is quite a black and white view, and that
there are situations this is not true).

Generally masking errors does not make them go away.

Frans