Bug 4515 - EMGD and X version information should not be in the machine config
Summary: EMGD and X version information should not be in the machine config
Status: RESOLVED FIXED
Alias: None
Product: BSPs
Classification: Build System, Metadata & Runtime
Component: bsps-meta-intel (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.6
Assignee: Nitin Kamble
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-05-20 18:13 UTC by Darren Hart
Modified: 2014-07-31 15:12 UTC (History)
1 user (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darren Hart 2013-05-20 18:13:06 UTC
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.
Comment 1 Tom Zanussi 2013-05-20 18:52:41 UTC
I'm not sure how much time we should really spend on emgd recipes, since they'll probably be considered legacy soon..
Comment 2 Darren Hart 2013-05-20 19:20:31 UTC
That is a good point, but this also has a generic component to it. It seems similar problems are present in other layers for similar reasons.
Comment 3 Darren Hart 2014-07-31 15:12:27 UTC
Fixed with option c, other layers are now doing something similar.