[OE-core] [PATCH 06/26] xinit: Update to 1.3.1

Joshua Lock josh at linux.intel.com
Fri Dec 9 19:01:50 UTC 2011


On 09/12/11 10:50, Mark Hatle wrote:
> On 12/9/11 12:42 PM, Paul Menzel wrote:
>> Dear Saul,
>>
>>
>> Am Dienstag, den 29.11.2011, 15:00 -0800 schrieb Saul Wold:
>>> Signed-off-by: Saul Wold<sgw at linux.intel.com>
>>> ---
>>>   .../xorg-app/{xinit_1.3.0.bb =>  xinit_1.3.1.bb}    |    6 +++---
>>>   1 files changed, 3 insertions(+), 3 deletions(-)
>>>   rename meta/recipes-graphics/xorg-app/{xinit_1.3.0.bb => 
>>> xinit_1.3.1.bb} (80%)
>>>
>>> diff --git a/meta/recipes-graphics/xorg-app/xinit_1.3.0.bb
>>> b/meta/recipes-graphics/xorg-app/xinit_1.3.1.bb
>>> similarity index 80%
>>> rename from meta/recipes-graphics/xorg-app/xinit_1.3.0.bb
>>> rename to meta/recipes-graphics/xorg-app/xinit_1.3.1.bb
>>> index 08dfe12..2ddebe6 100644
>>> --- a/meta/recipes-graphics/xorg-app/xinit_1.3.0.bb
>>> +++ b/meta/recipes-graphics/xorg-app/xinit_1.3.1.bb
>>> @@ -13,11 +13,11 @@ LIC_FILES_CHKSUM =
>>> "file://COPYING;md5=0d4b5eef75f1584ccbdc5e4a34314407"
>>>   PR = "r2"
>>
>> when upgrading recipes please remember to reset `PR` to 0. I just
>> spotted that now when looking through the “recent” changes [1].
> 
> I have not been doing that.  When I asked a while back the response I
> got was mixed and what I took from it is that PR (on a package upgrade)
> is up to the discretion of the person performing the upgrade.
> 
> If reseting to 0 is/should be the official policy, then we really need
> to document it as part of the patch/update guidelines..

My understanding is that the differing of opinion is between:
a) setting the PR = "0" in the recipe
b) deleting the PR entry from the recipe

Both of which set PR to 0, which I always understood to be 'policy'
unless there's a reason not to (usually meta-oe compatibility) but each
have their proponents for what makes most sense.

Regards,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre




More information about the Openembedded-core mailing list