[meta-freescale] [meta-fsl-arm-extra][PATCH] nitrogen6x.conf: Allow kernel provider override

[Otavio Salvador]

On Wed, Oct 30, 2013 at 2:56 PM, Daiane Angolini <daiane.list at gmail.com> wrote:
> On Wed, Oct 30, 2013 at 2:01 PM, Otavio Salvador
> <otavio at ossystems.com.br> wrote:
>> On Wed, Oct 30, 2013 at 12:44 PM, Gary Thomas <gary at mlbassoc.com> wrote:
>>> On 2013-10-30 08:33, Otavio Salvador wrote:
>>>>
>>>> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary at mlbassoc.com> wrote:
>>>>>
>>>>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary at mlbassoc.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> This change lets the user override the choice of kernel in local.conf
>>>>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>>>>> than the linux-boundary version.
>>>>>>>
>>>>>>> Signed-off-by: Gary Thomas <gary at mlbassoc.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I really dislike this.
>>>>>>
>>>>>> I understand your need, and it is a valid one, but it'd be better you
>>>>>> to make a new machine (which includes this one) and override it there.
>>>>>
>>>>>
>>>>> Even if I did that (and I have), if I include this config file, I can
>>>>> never override this setting in a soft (user settable) way.
>>>>
>>>>
>>>> Then you can force it in your machine.
>>>>
>>>>>> If we start allow all kind of override in machine configuration it
>>>>>> loses its meaning and complicates the support.
>>>>>>
>>>>>> Eric? comments?
>>>>>>
>>>>>
>>>>> Eric has already approved this change.
>>>>
>>>>
>>>> This is not up to me but I'd like to discuss it a little bit further
>>>> before merging it...
>>>>
>>>> My main concern about this is the support. As I said it is a valid
>>>> use-case but /most/ people will end with a .conf for the custom
>>>> settings in the end with their internal fork or so. Do it in
>>>> local.conf or environment is not advised as it is easy to be forgotten
>>>> or do wrong so for every product it is better to have a .conf in case
>>>> it needs specific kernel/u-boot patches.
>>>>
>>>
>>> A reasonable concern.  I do note that having this be soft in <MACHINE>.conf
>>> seems to be common practice in the rest of the Yocto world.
>>
>> Ok; you guys won :-)
>>
>> I applied it to dora and master (I manually applied it as it has not
>> applied cleanly).
>>
>> Eric, please, if you have time do the same change in nitrogen6x-lite
>> so it is kept in sync.
>
> I do agree with both sides. But I think you didn´t presented the
> complete set of possibilities. I mean, it´s not a "support" X
> "flexibility" fight.
>
> If nitrogen-any deserves to be flexible, so all other deserves it the same way.
>
> If it´s "wrong" for one board. It´s "wrong" for any. So, please submit
> the patch to fix all/every board.

Agreed here.

> As I really don´t have an strong position for this. I would say, let´s
> change and see what´s happens.
>
> For support nightmare, we always need to say what is
> u-boot/kernel/yocto problem in this ML, so the nightmare is already
> here.

:-(

> But, in my opinion, it´s NOT a bug fix, and should NOT be merged in dora.

Yes I agree it is not a bugfix but I think that it'd be better to be
consistent with dora and master at this point. Most people will keep
using dora for a while and it'd be better to have this deplyed now
than see how it goes in 1.6 only.

Comments?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750