Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default

From: Robert Yang <liezhi.yang@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
Date: Thu, 12 Sep 2013 15:23:46 +0800	[thread overview]
Message-ID: <52316C02.7090607@windriver.com> (raw)
In-Reply-To: <1378736079.3484.117.camel@ted>

I've done a world build on qemux86 with:

PROVIDES_prepend = "${PN} "

it worked well.

// Robert

On 09/09/2013 10:14 PM, Richard Purdie 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 <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 2d19d86..578c7d0 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -253,7 +253,7 @@ DEPCHAIN_POST = "-dev -dbg"
>   DEPENDS = ""
>   RDEPENDS = ""
>   PROVIDES = ""
> -PROVIDES_prepend = "${P} ${PF} ${PN} "
> +PROVIDES_prepend = "${PN} "
>   RPROVIDES = ""
>
>   MULTI_PROVIDER_WHITELIST = "virtual/libintl virtual/libintl-native virtual/nativesdk-libintl virtual/xserver virtual/update-alternatives-native virtual/update-alternatives"
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>