| Summary: | RDEPENDS does not work properly for native builds (only supports recipe names, not package names) | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Alexander Kanavin <alex.kanavin> |
| Component: | configuration | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | randy.macleod |
| Version: | unspecified | ||
| Target Milestone: | 3.3 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
Just to be clear whilst PACKAGES is empty there is:
native.bbclass:RPROVIDES = "${PN}"
which is why the PN value works as an RDEPENDS.
Bitbake isn't mixing the DEPENDS and RDEPENDS namespaces and this issue is entirely an OE-Core problem related to the way OE has handled native recipes.
We'd likely be able to do much better than the original situation where native recipes were entirely different to their target versions. Its really a question of someone having the time to unravel the mess and fix the issues. The question is then whether that is a lower or higher priority than all the other issues going on...
There is also an additional problem. The dependency mapping code in bbclass extend uses prefixes for a reason (nativesdk-bash, not bash-nativesdk). Somewhere there is an email from me which goes through all the options and explains why it was near impossible to implement a suffix extension which would work in all cases, it was only possible to make prefixes work generically. If we wanted to make -native work magically with packages, I think we'd run into that problem and I never did figure out a solution. http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c4257ed8b1040a5a0e9a95846d81961741239116 RDEPENDS_${PN} = 'libicuio' in the libyaml recipe now works as expected. |
RDEPENDS should be listing package names, not recipe names. Yet for native recipes, the package list is empty, as set by the native.bbclass. Which results in a situation where only recipe names are allowed in RDEPENDS, or otherwise bitbake will complain about missing dependencies. A reproducer: add RDEPENDS_${PN} = 'libicuio' to libyaml recipe. (libicuio is a package from icu recipe) Then libyaml builds, but libyaml-native fails: ERROR: Nothing RPROVIDES 'libicuio-native' (but virtual:native:/home/alexander/development/poky/meta/recipes-support/libyaml/libyaml_0.2.2.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'libicuio-native' is unbuildable, removing... Missing or unbuildable dependency chain was: ['libicuio-native'] ERROR: Required build target 'libyaml-native' has no buildable providers. Missing or unbuildable dependency chain was: ['libyaml-native', 'libicuio-native'] I do believe this is a proper bug. We work around it across many recipes by setting RDEPENDS_native to an empty string, but it should be addressed properly.