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

[Gary Thomas <gary@mlbassoc.com>]

On 2013-12-09 10:10, Otavio Salvador wrote:
> On Mon, Dec 9, 2013 at 3:05 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 2013-12-09 10:00, Otavio Salvador wrote:
>>>
>>> On Mon, Dec 9, 2013 at 2:59 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>
>>>> On 2013-12-09 09:55, Otavio Salvador wrote:
>>>>>
>>>>>
>>>>> On Mon, Dec 9, 2013 at 2:53 PM, Gary Thomas <gary@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.

-- 
----------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------