On Mon, Sep 9, 2013 at 7:14 AM, Richard Purdie < [email protected]> wrote:
> For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. > This looks > nice at first glance however it turns out to be a bit problematic. Taking > make as an > example where there are two versions, 3.81 and 3.82, what should "bitbake > make-3.81" do? > > Currently it builds make-3.81 and make-3.82 and breaks in interesting > ways. Is that > a bitbake bug? Well, it certainly shouldn't try and run the build. Why is > it building > 3.82 though? Its due to finding a dependency on "make-dev" and then trying > to figure > out what provides it? The answer is "make" and the default version of > "make" is 3.82. > > So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = > "3.81". Doing > so resolved the above problem since now "make" resolves to "make-3.81". > > So what about if we have Recipe A: > DEPENDS = "make-3.81" > and Recipe B: > DEPENDS = "make-3.82" > > That is clearly an error, easy. So finally what about if we have Recipe A: > DEPENDS = "make-3.81" > and Recipe B: > DEPENDS = "make" > > The first recipe infers the PREFERRED_VERSION_make = "3.81" and then > forces that > version on everything else. Is that desired? Probably not in most cases, > at least not > silently. > > As mitigation, we could print a WARNING about this happening. The final > part of the problem > is that we can ony figure this out within bitbake itself. That means we'd > have to teach bitbake > about the PN-PV format of PROVIDES which is breaking the separation > between bitbake and the > metadata. We can't win :(. > > Nobody that I know of is using or relying on this functionality so perhaps > we should > just remove it instead which is what this patch does. Opinions? > > Signed-off-by: Richard Purdie <[email protected]> > 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. -- Christopher Larson
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
