Re: [PATCH] insane.bbclass: add indirect-build-deps QA check

[Patrick Ohly <patrick.ohly@intel.com>]

On Wed, 2015-06-17 at 12:25 +0200, Patrick Ohly wrote:
> However, there are at least two false positives left in the current code:
> * aliases for recipes via PROVIDES
> * unnecessarily linking against libs which are not really used
> 
> See the TODOs in the code.

Actually, I had written more about that which didn't make it into the
posted patch. Here's the more complete comment:


                        # TODO: check PROVIDES of the rdepend recipe to see whether that is
                        # listed in DEPENDS. Example: "smack" instead of "userspace-smack" in
                        # https://github.com/01org/meta-intel-iot-security/blob/master/meta-security-smack/recipes-extended/libpam/libpam_%25.bbappend which is an alias for
                        # https://github.com/01org/meta-intel-iot-security/blob/master/meta-security-smack/recipes-security/smack/smack-userspace_git.bb

                        # TODO: pam-plugin-cracklib/lib/security/pam_cracklib.so is unecessarily
                        # linked against libz.so.1, probably because of link flags from libcrack,
                        # which is what libpam calls and (correctly) lists as DEPENDS.
                        # Because libz is not listed as DEPENDS, we warn about it here
                        # unnecessarily. This could be fairly common; not sure how to detect
                        # it though, short of comparing symbol tables.


> +                        # TODO: check PROVIDES of the rdepend recipe to see whether that is
> +                        # listed in DEPENDS.
> +                        error_msg = "%s rdepends on %s, but it only an indirect build dependency?" % (pkg, rdepend)
> +                        sane = package_qa_handle_error("indirect-build-deps", error_msg, d)

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.