From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7063 invoked by alias); 27 Sep 2012 04:43:57 -0000 Received: (qmail 7049 invoked by uid 22791); 27 Sep 2012 04:43:56 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,T_DKIM_INVALID X-Spam-Check-By: sourceware.org Received: from mail02.prevas.se (HELO mail02.prevas.se) (62.95.78.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Sep 2012 04:43:42 +0000 Received: from vmprevas3.prevas.se (HELO smtp.prevas.se) ([172.16.8.103]) by ironport2.prevas.se with ESMTP/TLS/AES128-SHA; 27 Sep 2012 06:43:41 +0200 Received: from dev.prevas.dk (172.16.10.60) by smtp.prevas.se (172.16.8.105) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 27 Sep 2012 06:43:41 +0200 Received: from arh128 (0x55532124.adsl.cybercity.dk [85.83.33.36]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eha) by dev.prevas.dk (Postfix) with ESMTPSA id E5ABA8012C; Thu, 27 Sep 2012 06:43:40 +0200 (CEST) Received: by arh128 (Postfix, from userid 1000) id 0F98B84BD7; Thu, 27 Sep 2012 06:43:40 +0200 (CEST) From: Esben Haabendal To: "Yann E. MORIN" CC: , Johannes Stezenbach Subject: Re: [RFC PATCH] allow arbitrary Linux kernel versions References: <20120926130754.GA26711@sig21.net> <201209261927.04071.yann.morin.1998@free.fr> <20120926201822.GA21265@sig21.net> <201209262323.30715.yann.morin.1998@free.fr> Date: Thu, 27 Sep 2012 04:43:00 -0000 In-Reply-To: <201209262323.30715.yann.morin.1998@free.fr> (Yann E. MORIN's message of "Wed, 26 Sep 2012 23:23:30 +0200") Message-ID: <87wqzgm5xg.fsf@arh128.prevas.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00133.txt.bz2 "Yann E. MORIN" writes: >> Ideally ct-ng would remember the major version and only >> update the minor, e.g. from gcc-linaro-4.6-2012.08 >> to gcc-linaro-4.6-2012.09. > > OK, that's a sane idea. > > Currently, the config does (roughly!): > > config GCC_V_linaro_4_6_2010_09 > bool "linaro-4.6-2012.09" > > config GCC_VERSION > string > default "linaro-4.6-2012.09" if GCC_V_linaro_4_6_2010_09 > > This could be changed to: > > config GCC_V_linaro_4_6 > bool "linaro-4.6 (2012.09)" > > config GCC_VERSION > string > default "linaro-4.6-2012.09" if GCC_V_linaro_4_6 > > Thus, the new config would "maintain" the linaro 'major' selection, and > only upgrade the 'minor' version. Is that the behavior you are suggesting? I for one would like to see that minor change in behavior :-) > And maybe we could use a similar scheme for other components, such as the > Linux kernel: > > - for the latest major release (eg. gcc-4.7 today), keep all sub-versions > - for previous major releases (eg. gcc-4.6, 4.5...), keep only the "major" > version ID in the config, and update the minor version only in the > "string" option, thus allowing to more easily forward a .config to a > newer ct-ng version. > > Could that be a correct answer to your issue? +1 :-) It would slightly easy upgrading of ct-NG in OE-lite. /Esben -- For unsubscribe information see http://sourceware.org/lists.html#faq