[oe] [PATCH] wpa-gui-e: build the latest version from git sources

Koen Kooi koen at dominion.thruhere.net
Wed May 25 14:12:45 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25-05-11 16:03, Paul Menzel wrote:
> Dear Andreas, dear Eyal,
> 
> 
> On Mi, 2011-05-25 at 15:36 +0200, Andreas Oberritter wrote:
> 
>> On 05/25/2011 02:58 PM, Eyal Reizer wrote:
> 
> […]
> 
>>> +SRCREV = "b8fb017272ed4794339978c9fbc0e74571a44728"
>>> +PR = "r0"
>>
>> PR = "r0" is the default and can be removed.
> 
> it seems there are different opinions on this topic. At least the manual
> says differently.
> 
>         Note
>         
>         It is good practice to always define PR in your recipes, even
>         for the "r0" release, so that when editing the recipe it is
>         clear that the PR number needs to be updated.
>         
>         You should always increment PR when modifying a recipe.
>         Sometimes this can be avoided if the change will have no effect
>         on the actual packages generated by the recipe, such as updating
>         the SRC_URI to point to a new host. If in any doubt then you
>         should increase the PR regardless of what has been changed.
>         
>         The PR value should never be decremented. If you accidentally
>         submit a large PR value for example then it should be left at
>         the value and just increased for new releases, not reset back to
>         a lower version.
> 
>>> +PV = "0.7.3+0.8.0-rc"
>>> +PR_append = "+gitr${SRCPV}"
>>
>> SRCPV should not be used in PR (even if it's been copied from another
>> recipe which does it wrong).
> 
> I am still confused about this one. That is why I still have not
> committed the pkg-config patch yet [2]. Could the right way be
> documented in the manual.

It is completely OK to use it in PR if you want the hash in PR, but not PV.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFN3Q5dMkyGM64RGpERAhwhAKCKxo/HdbjYY90JHWbgtyiGCMwLFQCgiaRa
HB1AMRMFaS/r4+iF6S6wa5M=
=XI4d
-----END PGP SIGNATURE-----





More information about the Openembedded-devel mailing list