From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo5.mail-out.ovh.net (8.mo5.mail-out.ovh.net [178.32.116.78]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 276E0E003DA for ; Fri, 14 Dec 2012 07:30:27 -0800 (PST) Received: from mail609.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo5.mail-out.ovh.net (Postfix) with SMTP id D31FC1054203 for ; Fri, 14 Dec 2012 16:38:58 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 14 Dec 2012 17:30:53 +0200 Received: from pac33-2-82-240-38-71.fbx.proxad.net (HELO eb-e6520) (eric%eukrea.com@82.240.38.71) by ns0.ovh.net with SMTP; 14 Dec 2012 17:30:53 +0200 Date: Fri, 14 Dec 2012 16:30:24 +0100 From: Eric =?ISO-8859-1?B?QuluYXJk?= To: Otavio Salvador X-Ovh-Mailout: 178.32.228.5 (mo5.mail-out.ovh.net) Message-ID: <20121214163024.7427cf1d@eb-e6520> In-Reply-To: References: <1355486234-7035-1-git-send-email-andrei.gherzan@windriver.com> <20121214145331.54c07822@eb-e6520> <20121214150150.1aa8eaf5@eb-e6520> <20121214151314.001f1ec8@eb-e6520> <20121214152619.79098454@eb-e6520> Organization: =?ISO-8859-1?B?RXVrculh?= Electromatique X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-Ovh-Tracer-Id: 5056697956733070716 X-Ovh-Remote: 82.240.38.71 (pac33-2-82-240-38-71.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehjedrtdelucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfhrhhomhepgfhrihgtuceurohnrghrugcuoegvrhhitgesvghukhhrvggrrdgtohhmqeenucfjughrpeffhffvuffkjghfohfogggtgfesthhqredtredtud X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehjedrtdelucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfhrhhomhepgfhrihgtuceurohnrghrugcuoegvrhhitgesvghukhhrvggrrdgtohhmqeenucfjughrpeffhffvuffkjghfohfogggtgfesthhqredtredtud Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm][PATCH 1/3] u-boot: Rename recipe to u-boot-fsl 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: Fri, 14 Dec 2012 15:30:27 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le Fri, 14 Dec 2012 13:14:54 -0200, Otavio Salvador a =E9crit : > On Fri, Dec 14, 2012 at 12:26 PM, Eric B=E9nard wrote: > > Le Fri, 14 Dec 2012 16:15:33 +0200, > > Andrei Gherzan a =E9crit : > >> What if uboot will have a git version in oe-core in the future? Or a > >> greater one. How would you fix that? I still think this is a good long= term > >> solution. > >> > > well, in that case the BSP recipe will be used as the layer has a higher > > priority. > > > > And to not have this kind of issue, you can simpy add the following > > lines to your BSP's u-boot recipe : > > DEFAULT_PREFERENCE =3D "-1" > > DEFAULT_PREFERENCE_machine =3D "1" > > > > or simply change to a u-boot_git.bbappend to just append your machine > > specific changes to oe-core's default recipe. > > > > or add something like this in your BSP conf file : > > PREFERRED_PROVIDER_virtual/kernel ?=3D "linux-yocto" > > PREFERRED_VERSION_linux-yocto =3D "3.4%" > > > > Check 1.2.9 in BSP Guide for examples on how this can be done (example > > for linux-yocto but the use case is the same here). >=20 > I agree it is a possible way of doing it however I also think we > should opt for a safe route. >=20 > The Andrei's proposal make it harder to it to behave strangely so I > think it is a good option for long term. Another positive result of it > is that the new name makes clear we're not really using u-boot > mainline but mainline + patches. I support this change as it improves > the clearness for new users. >=20 that's your choice but please note that you open the door to renaming any recipe : - either to workaround a problem in an other (or in your own) layer instead of really solving it - or simply each time you add a patch to a recipe which then becomes non mainline ! IMHO renaming the recipe is not the right way to do. Eric