* [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
@ 2013-09-09 14:14 Richard Purdie
2013-09-09 18:19 ` Chris Larson
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Richard Purdie @ 2013-09-09 14:14 UTC (permalink / raw)
To: openembedded-core
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"
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
2013-09-09 14:14 [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default Richard Purdie
@ 2013-09-09 18:19 ` Chris Larson
2013-09-10 7:33 ` Robert Yang
2013-09-12 7:23 ` Robert Yang
2 siblings, 0 replies; 8+ messages in thread
From: Chris Larson @ 2013-09-09 18:19 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
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.
--
Christopher Larson
[-- Attachment #2: Type: text/html, Size: 2738 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
2013-09-09 14:14 [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default Richard Purdie
2013-09-09 18:19 ` Chris Larson
@ 2013-09-10 7:33 ` Robert Yang
2013-09-10 14:08 ` Richard Purdie
2013-09-12 7:23 ` Robert Yang
2 siblings, 1 reply; 8+ messages in thread
From: Robert Yang @ 2013-09-10 7:33 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
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
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
2013-09-10 7:33 ` Robert Yang
@ 2013-09-10 14:08 ` Richard Purdie
2013-09-11 9:31 ` Robert Yang
0 siblings, 1 reply; 8+ messages in thread
From: Richard Purdie @ 2013-09-10 14:08 UTC (permalink / raw)
To: Robert Yang; +Cc: openembedded-core
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
2013-09-10 14:08 ` Richard Purdie
@ 2013-09-11 9:31 ` Robert Yang
2013-09-11 10:10 ` Richard Purdie
0 siblings, 1 reply; 8+ messages in thread
From: Robert Yang @ 2013-09-11 9:31 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
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
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
2013-09-11 9:31 ` Robert Yang
@ 2013-09-11 10:10 ` Richard Purdie
2013-09-12 2:17 ` Robert Yang
0 siblings, 1 reply; 8+ messages in thread
From: Richard Purdie @ 2013-09-11 10:10 UTC (permalink / raw)
To: Robert Yang; +Cc: openembedded-core
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
2013-09-11 10:10 ` Richard Purdie
@ 2013-09-12 2:17 ` Robert Yang
0 siblings, 0 replies; 8+ messages in thread
From: Robert Yang @ 2013-09-12 2:17 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
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
>
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default
2013-09-09 14:14 [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default Richard Purdie
2013-09-09 18:19 ` Chris Larson
2013-09-10 7:33 ` Robert Yang
@ 2013-09-12 7:23 ` Robert Yang
2 siblings, 0 replies; 8+ messages in thread
From: Robert Yang @ 2013-09-12 7:23 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
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
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-09-12 7:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-09 14:14 [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default Richard Purdie
2013-09-09 18:19 ` Chris Larson
2013-09-10 7:33 ` Robert Yang
2013-09-10 14:08 ` Richard Purdie
2013-09-11 9:31 ` Robert Yang
2013-09-11 10:10 ` Richard Purdie
2013-09-12 2:17 ` Robert Yang
2013-09-12 7:23 ` Robert Yang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox