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

login
register
mail settings
Submitter Richard Purdie
Date Sept. 9, 2013, 2:14 p.m.
Message ID <1378736079.3484.117.camel@ted>
Download mbox | patch
Permalink /patch/57667/
State Accepted
Commit 493e8b46fdad9a4a0363ab9e614de122d4ea140d
Headers show

Comments

Richard Purdie - Sept. 9, 2013, 2:14 p.m.
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>
---
Chris Larson - Sept. 9, 2013, 6:19 p.m.
On Mon, Sep 9, 2013 at 7:14 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> 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>
>

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.
Robert Yang - Sept. 10, 2013, 7:33 a.m.
Hi RP,

Thanks, Can we provide a replacement for the "bitbake PN-PV" since it is
useful, for example, can we support the PREFERRED_VERSION_${PN} in the env
in the future ? There is a similar bug:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4965

// 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
>
>
Richard Purdie - Sept. 10, 2013, 2:08 p.m.
On Tue, 2013-09-10 at 15:33 +0800, Robert Yang wrote:
> Thanks, Can we provide a replacement for the "bitbake PN-PV" since it is
> useful, for example, can we support the PREFERRED_VERSION_${PN} in the env
> in the future ? There is a similar bug:
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4965

If you set BB_PRESERVE_ENV=1 you can set PREFERRED_VERSION_xxx from the
environment so this should already be possible?

Cheers,

Richard
Robert Yang - Sept. 11, 2013, 9:31 a.m.
On 09/10/2013 10:08 PM, Richard Purdie wrote:
> On Tue, 2013-09-10 at 15:33 +0800, Robert Yang wrote:
>> Thanks, Can we provide a replacement for the "bitbake PN-PV" since it is
>> useful, for example, can we support the PREFERRED_VERSION_${PN} in the env
>> in the future ? There is a similar bug:
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4965
>
> If you set BB_PRESERVE_ENV=1 you can set PREFERRED_VERSION_xxx from the
> environment so this should already be possible?
>

It seems that the BB_PRESERVE_ENV=1 doesn't work, but we use the
BB_ENV_EXTRAWHITE, for example:

$ export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE PREFERRED_VERSION_make"
$ export PREFERRED_VERSION_make="3.81",

Then it works, maybe something is wrong with the BB_PRESERVE_ENV.

// Robert

> Cheers,
>
> Richard
>
>
>
Richard Purdie - Sept. 11, 2013, 10:10 a.m.
On Wed, 2013-09-11 at 17:31 +0800, Robert Yang wrote:
> 
> On 09/10/2013 10:08 PM, Richard Purdie wrote:
> > On Tue, 2013-09-10 at 15:33 +0800, Robert Yang wrote:
> >> Thanks, Can we provide a replacement for the "bitbake PN-PV" since it is
> >> useful, for example, can we support the PREFERRED_VERSION_${PN} in the env
> >> in the future ? There is a similar bug:
> >>
> >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4965
> >
> > If you set BB_PRESERVE_ENV=1 you can set PREFERRED_VERSION_xxx from the
> > environment so this should already be possible?
> >
> 
> It seems that the BB_PRESERVE_ENV=1 doesn't work, but we use the
> BB_ENV_EXTRAWHITE, for example:
> 
> $ export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE PREFERRED_VERSION_make"
> $ export PREFERRED_VERSION_make="3.81",
> 
> Then it works, maybe something is wrong with the BB_PRESERVE_ENV.

It is broken, yes, I've sent out a patch to fix it. There is one other
problem, you can't use "-" in a shell environment variable so you can't
do:

PREFERRED_VERSION_make-native = xxx

which is annoying. We might want to add some kind of mangling mechanism
like a double underscore translating to a dash or something...

Cheers,

Richard
Robert Yang - Sept. 12, 2013, 2:17 a.m.
On 09/11/2013 06:10 PM, Richard Purdie wrote:
> On Wed, 2013-09-11 at 17:31 +0800, Robert Yang wrote:
>>
>> On 09/10/2013 10:08 PM, Richard Purdie wrote:
>>> On Tue, 2013-09-10 at 15:33 +0800, Robert Yang wrote:
>>>> Thanks, Can we provide a replacement for the "bitbake PN-PV" since it is
>>>> useful, for example, can we support the PREFERRED_VERSION_${PN} in the env
>>>> in the future ? There is a similar bug:
>>>>
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4965
>>>
>>> If you set BB_PRESERVE_ENV=1 you can set PREFERRED_VERSION_xxx from the
>>> environment so this should already be possible?
>>>
>>
>> It seems that the BB_PRESERVE_ENV=1 doesn't work, but we use the
>> BB_ENV_EXTRAWHITE, for example:
>>
>> $ export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE PREFERRED_VERSION_make"
>> $ export PREFERRED_VERSION_make="3.81",
>>
>> Then it works, maybe something is wrong with the BB_PRESERVE_ENV.
>
> It is broken, yes, I've sent out a patch to fix it. There is one other

Thanks, it worked now.

> problem, you can't use "-" in a shell environment variable so you can't
> do:
>
> PREFERRED_VERSION_make-native = xxx
>
> which is annoying. We might want to add some kind of mangling mechanism
> like a double underscore translating to a dash or something...
>

I will update these in the bugzilla

// Robert

> Cheers,
>
> Richard
>
>
>
>
Robert Yang - Sept. 12, 2013, 7:23 a.m.
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
>
>

Patch

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"