[poky] [PATCH 0/1] poky.conf: explicitly referenced preferred linux-yocto version

[Darren Hart]

On 07/25/2011 01:16 PM, Tom Rini wrote:
> On 07/25/2011 12:04 PM, Bruce Ashfield wrote:
>> On Mon, Jul 25, 2011 at 2:59 PM, Tom Rini <tom_rini at mentor.com> wrote:
>>> On 07/25/2011 11:50 AM, Bruce Ashfield wrote:
>>>> On Mon, Jul 25, 2011 at 2:42 PM, Tom Rini <tom_rini at mentor.com> wrote:
>>>>> On 07/25/2011 11:05 AM, Bruce Ashfield wrote:
>>>>>> Here's a similar change to the meta-yocto boards, as was done
>>>>>> to the qemu machines in oe-core. Since referencing yocto makes
>>>>>> more sense in this layer, I made the change in the poky.conf
>>>>>> distro default file.
>>>>>>
>>>>>> As the staging of linux-yocto-3.0 showed, we should explicitly
>>>>>> state our preferred version of linux-yocto. This prevents unvalidated
>>>>>> changes from being forced into machines. Layers and machines are free
>>>>>> to override this as they are updated.
>>>>>>
>>>>>> cc: Tom Zanussi <tom.zanussi at intel.com>
>>>>>>
>>>>>> The following changes since commit dfec64a66e66ad4ec94a06ad900307fb0d932b98:
>>>>>>
>>>>>>   machine/qemu: set preferred linux-yocto kernel version (2011-07-25 10:56:46 -0400)
>>>>>>
>>>>>> are available in the git repository at:
>>>>>>   git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
>>>>>>   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto
>>>>>>
>>>>>> Bruce Ashfield (1):
>>>>>>   poky.conf: explicitly referenced preferred linux-yocto version
>>>>>>
>>>>>>  meta-yocto/conf/distro/poky.conf |    2 ++
>>>>>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>>>>
>>>>> I guess as an aside, the convention we have/had in oe.dev was
>>>>> DEFAULT_PREFERENCE = -1, D_P_testedmachine1 = 1, etc, etc, in the kernel
>>>>> recipes.
>>>>
>>>> I've noticed that .. and it would work here as well. I'm hesitant to
>>>> maintain a set of tested machine overrides in the yocto layers, since
>>>> we are at a small number now, but that number isn't guaranteed to
>>>> stay small. I have enough of a pain updating SRCREVs constantly,
>>>> tweaking another set of vars isn't high on my 'fun' list.
>>>>
>>>> I prefer to have the machines opt-in, versus maintaining a list of known
>>>> good machines in a central file (I realize that the machines would/could
>>>> be the ones setting the default_preference back to 1 as wel, but it is
>>>> still another variable to manipulate). But am not religious about any of this :)
>>>>
>>>> The flip to 3.0 is sort of a special case, and typically it is just a switch
>>>> I throw, since all machines are tested at once.
>>>>
>>>> Good comment and food for thought indeed!
>>>
>>> So, if you go down the D_P route, meta-$whatever has
>>> linux_testedVer.bbappend D_P = "1" in it for what it wants to opt into
>>> and the meta-yocto / oe-core recipes just stay having to track qemu
>>> machines, too.
>>
>> Understood, that's what I tried to say (badly) when I mentioned that the
>> machines could set this variable in their own layer, versus a central
>> update.
>>
>> The question that pops up for me, what's the pros and cons of this
>> versus the machine setting a version preference by machine specific
>> overrides (maybe they can't?) or setting their compatibility variables.
>> I can see that this is an explicit statement of tested versus not
>> tested, versus something more implicit. But are there others ?
> 
> To me, it boils down to where do you make the pain point.  If it's in
> the kernel recipe (/ bbappend), we don't cause a re-parse of the
> metadata.  It can however be arguably more of a surprise when the kernel
> upgrades.  With my Mentor hat, we've always pinned the recipe version
> down for the kernel, but with my community hat, building the latest
> that's supposed to work feels best.

How do DEFAULT_PREFERENCE and PREFERRED_VERSION relate to each other?
Does one trump the other?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel