| Summary: | Investigate binary component functionality | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Stephano Cetola <stephano> |
| Component: | core | Assignee: | Stephano Cetola <stephano> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | jose.perez.carranza, joshuagloe, meta.mr.watcher, meta.watcher |
| Version: | 2.2 | ||
| Target Milestone: | 2.3 M1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
| Bug Depends on: | |||
| Bug Blocks: | 10663 | ||
|
Description
Stephano Cetola
2016-11-14 22:49:35 UTC
Things we should probably be checking: 1. Check for updates to the BSP that break compatibility 2. Check for customer-layer changes that break compatibility 3. Generate list of checks based on things like objdump, readelf, and ldd 4. Allow list of checks to be configurable (extendable?) by recipes As an example (from PCCG): They have two recipes: 1 for the creation of the binary and another recipe that the customer uses to deploy the binary to their rootfs. Problems they would like to solve: 1. The two recipes do not know about each other, so the user could technically include both recipes (which should throw a very obvious error). 2. If they change the location of libraries, older binaries will no longer be compatible. There is currently no check in place for this situation. They currently use PREFERRED_PROVIDER in the binary recipe, to ensure the correct version is installed. 3. If the customer changes something in their layer which breaks compatibility, the binary will simply break without any warnings or errors at build-time. |