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

[Tom Rini]

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.

-- 
Tom Rini
Mentor Graphics Corporation