Patchwork dmidecode: fix fetch path to use BP

login
register
mail settings
Submitter Saul Wold
Date May 3, 2013, 11:06 p.m.
Message ID <1367622401-28624-1-git-send-email-sgw@linux.intel.com>
Download mbox | patch
Permalink /patch/49321/
State Accepted
Commit b5d5b1bfa49a3765b907f6b68cdb68ddec365e06
Headers show

Comments

Saul Wold - May 3, 2013, 11:06 p.m.
This is so the multilib prefix is not used

Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
 meta/recipes-devtools/dmidecode/dmidecode_2.12.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Darren Hart - May 4, 2013, 2:41 a.m.
On 05/03/2013 04:06 PM, Saul Wold wrote:
> This is so the multilib prefix is not used

Thanks for catching that Saul. How do we know when to use P and when to
use BP? Where should this be documented? Maybe in the dev manual for
writing new recipes?

--
Darren


> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
>  meta/recipes-devtools/dmidecode/dmidecode_2.12.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb b/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
> index bdddf30..000d2cd 100644
> --- a/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
> +++ b/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
> @@ -4,7 +4,7 @@ LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=393a5ca445f6965873eca0259a17f833"
>  PR = "r0"
>  
> -SRC_URI = "http://savannah.nongnu.org/download/dmidecode/${P}.tar.bz2"
> +SRC_URI = "http://savannah.nongnu.org/download/dmidecode/${BP}.tar.bz2"
>  
>  COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
>  
>
Paul Eggleton - May 4, 2013, 8:11 a.m.
On Friday 03 May 2013 19:41:03 Darren Hart wrote:
> On 05/03/2013 04:06 PM, Saul Wold wrote:
> > This is so the multilib prefix is not used
> 
> Thanks for catching that Saul. How do we know when to use P and when to
> use BP? 

The easiest thing is to imagine what would happen were the recipe to be 
BBCLASSEXTENDed to native - would xyz-native make sense where you've used the 
reference, or does it always need to be xyz regardless of how it is being 
built? If the former, PN (or P with the version); if the latter, BPN (or BP 
with the version).

> Where should this be documented? Maybe in the dev manual for
> writing new recipes?

It was pointed out recently on IRC that we may need to expand and adjust the 
section in the dev manual so it provides more of a step-by-step guide to 
creating a recipe, and I plan to work with Scott to do that for this cycle, so 
we should be able to include this as part of that.

Cheers,
Paul
Ross Burton - May 4, 2013, 6:54 p.m.
On 4 May 2013 09:11, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> The easiest thing is to imagine what would happen were the recipe to be
> BBCLASSEXTENDed to native - would xyz-native make sense where you've used the
> reference, or does it always need to be xyz regardless of how it is being
> built? If the former, PN (or P with the version); if the latter, BPN (or BP
> with the version).

I've been hitting errors related to this when doing ML builds which is
a good one for breakage as PN gets prefixed, and fixing where they
were causing errors.  I was thinking it would make sense for some
common-sense sanity checks to be done - ie SRC_URI shouldn't contain
PN, FILES_foo shouldn't contain BPN (the foo bit, that is), and so on.

Ross
Darren Hart - May 4, 2013, 7:25 p.m.
On 05/04/2013 01:11 AM, Paul Eggleton wrote:
> On Friday 03 May 2013 19:41:03 Darren Hart wrote:
>> On 05/03/2013 04:06 PM, Saul Wold wrote:
>>> This is so the multilib prefix is not used
>>
>> Thanks for catching that Saul. How do we know when to use P and when to
>> use BP? 
> 
> The easiest thing is to imagine what would happen were the recipe to be 
> BBCLASSEXTENDed to native - would xyz-native make sense where you've used the 
> reference, or does it always need to be xyz regardless of how it is being 
> built? If the former, PN (or P with the version); if the latter, BPN (or BP 
> with the version).
> 
>> Where should this be documented? Maybe in the dev manual for
>> writing new recipes?
> 
> It was pointed out recently on IRC that we may need to expand and adjust the 
> section in the dev manual so it provides more of a step-by-step guide to 
> creating a recipe, and I plan to work with Scott to do that for this cycle, so 
> we should be able to include this as part of that.
> 
> Cheers,
> Paul


Thank you Paul!

Patch

diff --git a/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb b/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
index bdddf30..000d2cd 100644
--- a/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
+++ b/meta/recipes-devtools/dmidecode/dmidecode_2.12.bb
@@ -4,7 +4,7 @@  LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=393a5ca445f6965873eca0259a17f833"
 PR = "r0"
 
-SRC_URI = "http://savannah.nongnu.org/download/dmidecode/${P}.tar.bz2"
+SRC_URI = "http://savannah.nongnu.org/download/dmidecode/${BP}.tar.bz2"
 
 COMPATIBLE_HOST = "(i.86|x86_64).*-linux"