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

[Otavio Salvador]

On Mon, Dec 9, 2013 at 3:31 PM, Gary Thomas <gary at mlbassoc.com> wrote:
> On 2013-12-09 10:10, Otavio Salvador wrote:
>>
>> 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.
>>
>
> Here's what I want to be able to support: I'm building my
> own targets (actual hardware) and I start from some version
> of u-boot-fslc, linux-boundary, etc.  My local working copies
> of that are based on a particular version and I want to still
> use the same recipes from meta-fsl-arm* even if they are updated
> for more recent versions.  This is even more important for the
> kernel.  I have boards that are based on boundary-imx_3.0.35_4.0.0
> but the meta-fsl-arm* recipes are now based on boundary-imx_3.0.35_4.1.0.
> Note that the recipe linux-boundary_3.0.35.bb didn't change names
> or even version numbers when the branch was changed. Without the ability
> to override the branch in my .bbappend, I can't use the meta-fsl-arm*
> recipe at all and would end up having to clone it which is really
> bad/unacceptable.
>
> I would not be using this in a way that the version being built was
> different than the recipe version implied.  If, for example, meta-fsl-arm*
> replaces u-boot-fslc_2013.10.bb with u-boot-fslc_2013.12.bb (and dropped
> the older u-boot-fslc_2013.10.bb), just like  you I would not find it
> acceptable to use .bbappend to go back to the 2013.10 branch/version.
> In that case, I would clone the 2013.10 recipe into my own layer(s).
> I just try to use the main layers as much as possible.

Right but I fail to understand how changing branch will make it work
for you if you're using a repository which you cannot push...

All the rest I fully agree.

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