2011/1/27 Thomas Zimmermann <[email protected]>: > 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
