[meta-freescale] [meta-fsl-arm][PATCH] u-boot-fslc: Add tag to git SRC_URI

[Otavio Salvador]

On Mon, Dec 9, 2013 at 3:05 PM, Gary Thomas <gary at mlbassoc.com> wrote:
> On 2013-12-09 10:00, Otavio Salvador wrote:
>>
>> On Mon, Dec 9, 2013 at 2:59 PM, Gary Thomas <gary at mlbassoc.com> wrote:
>>>
>>> On 2013-12-09 09:55, Otavio Salvador wrote:
>>>>
>>>>
>>>> On Mon, Dec 9, 2013 at 2:53 PM, Gary Thomas <gary at mlbassoc.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Do you have an use example where you'd need it?
>>>>>>>
>>>>>> I think he means to do something like this:
>>>>>>
>>>>>> GITTAG ??= "patches-2013.10"
>>>>>> SRC_URI = "git://github.com/Freescale/u-boot-imx.git;tag=${GITTAG}"
>>>>>>
>>>>>> This way he can override GITTAG in his .bbappend, correct?
>>>>>
>>>>>
>>>>>
>>>>> Correct.  The ??= isn't even necessary since the .bbappend can
>>>>> always override it.
>>>>
>>>>
>>>>
>>>> In this case you're using an old version of the bootloader in your
>>>> internal BSP, right? I'd expect you to add an .bb file for this
>>>> version instead and use PREFERRED_VERSION to use it.
>>>
>>>
>>>
>>> Why should I do that when .bbappend works perfectly well?  I can also
>>> see this as a case when new boards are added or old ones are still
>>> around and they get updated on different schedules.
>>>
>>> Also, what does it hurt to be flexible?
>>
>>
>> In this case you'd have a 2013.10 recipe building/installing a 2013.04
>> version for example, this is misleading and confusing for someone
>> using the BSP.
>>
>
> You do what you want - I just hope that I don't end up having
> to clone all of meta-fsl-arm* just because you fear a little
> flexibility :-(

I think you got me wrong.

The discussion here is to try to identify needs and try to come with
clean solution which works most people while keep it clean and simple
to understand as possible.

I think it is quite confusing when someone seems a bbappend which
changes a recipe for an old version and this does not match the recipe
name. I am fully aware this is /possible/ to do but this does not mean
this is advisable or desired.

I think that John's proposed solution is going to address both concerns well.

-- 
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