| Summary: |
EMGD and X version information should not be in the machine config |
| Product: |
[Build System, Metadata & Runtime] BSPs
|
Reporter: |
Darren Hart <dvhart> |
| Component: |
bsps-meta-intel | Assignee: |
Nitin Kamble <nitin.a.kamble> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
|
| Severity: |
normal
|
|
|
| Priority: |
Medium
|
CC: |
tom.zanussi
|
| Version: |
unspecified | |
|
| Target Milestone: |
1.6 | |
|
| Hardware: |
x86 | |
|
| OS: |
Multiple | |
|
| Whiteboard: |
|
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|---|
|
Verified:
|
|
Documentation change:
|
No (bug/feature does not impact docs)
|
|---|
The version information in many of the EMGD BSPs is in the machine config while it is really EMGD version specific, and should instead be included in the EMGD recipe. Richard has provided some brainstorming on this, and I confess I don't understand the packaging details well enough to boil this down any further. Copying his thoughts here for now (these need to be refined and researched further): > a) Fix the dependency code to ensure we have hard version dependencies > in the packages themselves (the RDEPENDS). This would mean we have to > have two versions of a given package in the feeds which in turn would > mean that distro maintainers may need to change their scripts to detect > and account for this. The idea would be to scan and see if a version is > required anywhere when updating the feed, if not, only them remove > duplicates which is doable (and the way other non-OE distros work). > > We may also have to improve bitbake's handling of DEPENDS versions or > something which will be hard, otherwise we still need the > PREFERRED_VERSION entries. I wonder if bitbake could internally convert > DEPENDS versions to P_V syntax, erroring if duplicates are hit? > > What we may have to do is add something like COMPATIBLE_MACHINE to the > emgd pieces so the special versions only get used for that specific > machine's builds. > > b) Make the "special" versions some particular package architecture for > the packages in question. Thinking about this, this adds in a lot of > complexity and I'm not sure it buys us anything over a). > > c) Rename the package namespace for emgd specific versions of things. > Again, I think this is ugly and the more I think about it, the more I > believe we're simply avoiding tackling the real issues in a) :/. > > d) Something else, proposals welcome.