<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 7:14 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":fz" style="overflow:hidden">For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. This looks<br>
nice at first glance however it turns out to be a bit problematic. Taking make as an<br>
example where there are two versions, 3.81 and 3.82, what should "bitbake make-3.81" do?<br>
<br>
Currently it builds make-3.81 and make-3.82 and breaks in interesting ways. Is that<br>
a bitbake bug? Well, it certainly shouldn't try and run the build. Why is it building<br>
3.82 though? Its due to finding a dependency on "make-dev" and then trying to figure<br>
out what provides it? The answer is "make" and the default version of "make" is 3.82.<br>
<br>
So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = "3.81". Doing<br>
so resolved the above problem since now "make" resolves to "make-3.81".<br>
<br>
So what about if we have Recipe A:<br>
DEPENDS = "make-3.81"<br>
and Recipe B:<br>
DEPENDS = "make-3.82"<br>
<br>
That is clearly an error, easy. So finally what about if we have Recipe A:<br>
DEPENDS = "make-3.81"<br>
and Recipe B:<br>
DEPENDS = "make"<br>
<br>
The first recipe infers the PREFERRED_VERSION_make = "3.81" and then forces that<br>
version on everything else. Is that desired? Probably not in most cases, at least not<br>
silently.<br>
<br>
As mitigation, we could print a WARNING about this happening. The final part of the problem<br>
is that we can ony figure this out within bitbake itself. That means we'd have to teach bitbake<br>
about the PN-PV format of PROVIDES which is breaking the separation between bitbake and the<br>
metadata. We can't win :(.<br>
<br>
Nobody that I know of is using or relying on this functionality so perhaps we should<br>
just remove it instead which is what this patch does. Opinions?<br>
<br>
Signed-off-by: Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>></div></blockquote></div><br>This sounds like a good plan to me. We never *really* supported version specific build dependencies anyway, and using those provides just caused problems. Better for it to go away entirely.<br>
-- <br>Christopher Larson</div></div>