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

[Bruce Ashfield]

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 ?

Cheers,

Bruce

>
> --
> Tom Rini
> Mentor Graphics Corporation
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"