[yocto] Unhandled dependency checking

[Paul Eggleton]

Hi Wolfgang,

On Friday 02 August 2013 15:36:50 Wolfgang Denk wrote:
> I'm looking ofr a good way to deal with some build breakages caused by
> missing dependency checking.
>
> The problem: some packages require certain capabilities, without
> checking for these, and actually I can;t see a good way how to
> implement such checking.
> 
> For example, the "lttng" package requires module support.  But when
> you modify the defconfig for the Linux kernel and disable module
> support there, then the build for "lttng" will break.

It's true that specifically for the kernel we have no intrinsic way of 
verifying from the recipe that appropriate kernel functionality is enabled. It 
probably wouldn't be too hard to add a mechanism that looked at 
${STAGING_KERNEL_DIR}/.config for specific values; in fact I notice that the 
systemtap-uprobes recipe does this. However this is only really appropriate 
for recipes that are specific to the machine and that have virtual/kernel in 
DEPENDS.

> Is there some good way to handle or at least to test for such "hidden"
> dependencies on features provided by other packages, so we could at
> least issue more useful error messages to the end user?

So in the general case, not really; usually there is no way to introspect 
these dependencies if they have not been explicitly declared. We do now 
however have a script that can be used to find undeclared dependencies 
(scripts/test-dependencies.sh), but the way this operates is to run several 
builds and it does take quite a bit of time.

I've thought about the possibility of doing a comparison of runtime 
dependencies after packaging and DEPENDS as a QA check to see if anything was 
missing; I don't know how practical this would be however.

Also, over the years there has also been discussion about using per-recipe 
sysroots, so that the sysroot used by an individual recipe only ever contains 
what has been declared in DEPENDS and thus wouldn't be able to auto-detect 
anything else. Of course this would significantly increase both build system 
complexity and disk space requirements.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre