[OE-core] [PATCH 17/17] package.bbclass: make unshipped files a fatal error

[Dmitry Eremin-Solenikov]

On 9/22/11, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2011-09-21 at 22:40 +0400, Dmitry Eremin-Solenikov wrote:
>> I belive that "files were installed but not shipped in any package"
>> message should become a fatal error. While it's true that sometimes some
>> files are generated by do_install task, which aren't necessary for our
>> target systems. However in generic I think this is a very important and
>> usually overlooked QA sign. E.g. recently I've found/fixed some bugs in
>> eglibc packaging only due to making this a fatal error. Sometimes new
>> versions of a software add new files, but then they are sometimes
>> ignored, as this messages can be easily missed. You can come with more
>> examples if you'd like to.
>>
>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>
>> ---
>>  meta/classes/package.bbclass |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
>> index a9c510d..f4a535e 100644
>> --- a/meta/classes/package.bbclass
>> +++ b/meta/classes/package.bbclass
>> @@ -948,6 +948,7 @@ python populate_packages () {
>>  		bb.warn("For recipe %s, the following files were installed but not
>> shipped in any package:" % pn)
>>  		for f in unshipped:
>>  			bb.warn("  " + f)
>> +		bb.fatal("Unshipped files found")
>>
>>  	bb.build.exec_func("package_name_hook", d)
>
> One of thee post-release things I want to sort out is the QA warnings
> and I add this warning under that category. We introduced the ideas of
> warnings to error and warn on into the QA class already and I'd like to
> be able to control this warning in that way using the same variables.

Nice idea! On the rights of a feature request:
It would be nice to allow user to:
1) specify the severity of the QA problems (warn, error, fatal) on a
global + per-qa-check level
2) specify an override for some of the checks, so that the packager
can specify that
e.g. QA check for .so links in a non-dev packages should be ignored
for cgroups-pam package for /lib/security/pam*.so lib. (I get the idea
from Debian lintian overrides. Hope
I was able to write what I mean).

>
> Also, rather than being bb.fatal, this should be bb.error. An Error
> message will allow the build to complete but will set the bitbake exit
> code to show when errors have occurred. This means errors still light
> the autobuilder up red when they occur so we're usually pretty good
> about noticing and removing error messages.

Hmmm. If it's a bb.error, is it logged somewhere except in the task log file?
Because even if I see a red state in my oestats installation (BTW:
what is the current way to track build statuses?), I don't think I'll
be able to dig through multi-page oestats task output for some big
image looking for erroneous-but-not-failed items.

-- 
With best wishes
Dmitry