Hello,

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.

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?

Thanks in advance.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
The rule on staying alive as a program manager is to give 'em a num-
ber or give 'em a date, but never give 'em both at once.

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