From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.chez-thomas.org (mail.mlbassoc.com [65.100.170.105]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 85826E005B1 for ; Mon, 9 Dec 2013 09:31:04 -0800 (PST) Received: by mail.chez-thomas.org (Postfix, from userid 1998) id 76411F81221; Mon, 9 Dec 2013 10:31:04 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hermes.chez-thomas.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.3.2 Received: from [192.168.1.114] (zeus [192.168.1.114]) by mail.chez-thomas.org (Postfix) with ESMTP id 9E9AFF8121E; Mon, 9 Dec 2013 10:30:59 -0700 (MST) Message-ID: <52A5FE84.8000203@mlbassoc.com> Date: Mon, 09 Dec 2013 10:31:48 -0700 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Otavio Salvador References: <1386605416-19779-1-git-send-email-rjohnweber@gmail.com> <52A5EF29.3040902@mlbassoc.com> <52A5EFA1.5060806@gmail.com> <52A5F142.70807@mlbassoc.com> <52A5F3BA.3030502@gmail.com> <52A5F58A.4080301@mlbassoc.com> <52A5F6F0.9080109@mlbassoc.com> <52A5F868.3040304@mlbassoc.com> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm][PATCH] u-boot-fslc: Add tag to git SRC_URI X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 17:31:06 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-12-09 10:10, Otavio Salvador wrote: > On Mon, Dec 9, 2013 at 3:05 PM, Gary Thomas wrote: >> On 2013-12-09 10:00, Otavio Salvador wrote: >>> >>> On Mon, Dec 9, 2013 at 2:59 PM, Gary Thomas wrote: >>>> >>>> On 2013-12-09 09:55, Otavio Salvador wrote: >>>>> >>>>> >>>>> On Mon, Dec 9, 2013 at 2:53 PM, Gary Thomas 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 ------------------------------------------------------------