From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S6jF2-0005WT-VO for mharc-grub-devel@gnu.org; Sun, 11 Mar 2012 09:55:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6jF0-0005Vz-0e for grub-devel@gnu.org; Sun, 11 Mar 2012 09:55:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6jEx-0000P6-L1 for grub-devel@gnu.org; Sun, 11 Mar 2012 09:55:17 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:64976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6jEx-0000Om-9R for grub-devel@gnu.org; Sun, 11 Mar 2012 09:55:15 -0400 Received: by wibhm17 with SMTP id hm17so2085977wib.0 for ; Sun, 11 Mar 2012 06:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=A9HEDQ3EGM2LD1EZBIELwCPohPaS/yA0Y0o3T2s/9L4=; b=cNZN89HDw8vhBBouWXuApeUsHkrQjMcA1y5kseE6229wwCYPf6wLossaEh5PzaxuSp qADSxGM5I3T1nYyIcTXA1bJju7NnLbQFP9oMsV+Vri3NnP6fht3HCzGT2UofRRe+/p2y ZDmH15xJEXxuPs1miEv9p9zshm1EKj1Fli/rqeTUxRap9XToKrJS7wOLeRdkfRiGGjjk 3JCX0GHGcSiHAWxq2/O/fJhg/yNNoVFE6T+Ce5XMtwYp6z/ZXP9xnsDs9dxZGE1cFqM3 46HK3zmoV1hYPa77z6WTVukAkXw11qIwYg4sKdaZQ5GJMxARyP++8UdxXGHvPd18V2by O6Aw== Received: by 10.180.83.198 with SMTP id s6mr19635637wiy.8.1331474113011; Sun, 11 Mar 2012 06:55:13 -0700 (PDT) Received: from [192.168.178.55] (p5091C0D0.dip.t-dialin.net. [80.145.192.208]) by mx.google.com with ESMTPS id w14sm24419910wiv.11.2012.03.11.06.55.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 06:55:12 -0700 (PDT) Message-ID: <4F5CAEBE.3060905@googlemail.com> Date: Sun, 11 Mar 2012 14:55:10 +0100 From: Andreas Born User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120220 Thunderbird/10.0.2 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Grub version variable in shell References: <4F5C10A0.1060802@googlemail.com> <4F5C1321.1050403@gmail.com> <4F5C920D.7070808@googlemail.com> <4F5C9ECF.5010707@gmail.com> In-Reply-To: <4F5C9ECF.5010707@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 13:55:19 -0000 Am 11.03.2012 13:47, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > Why not define "feature_bugXYZ_fixed" for bugs? > Which ones are missing in 2.00~beta1? In 1.98 there was that export issue, I already mentioned. When opening a new context with configfile e.g. variables were exported to the new context, but not marked anymore for reexport. So you had to reexport them yourself. No way I'm maintaining a workaround for that. Then there were some pecularities regarding identifiers I think. Like I (always) had to use ${cfgprefix} and not $cfgprefix. Back then I was also using for some reason function identifiers with quotes: function 'initmenu()' Generally, I remember that versions parser to be very picky. Some new features, which I use in my menu are: - localization - keymap (if keymap is probably fine here) - gfxpayload - read (or was that already there and I did not use it, if read could be problematic here though) - terminal_input at_keyboard (if keymap maybe too?) That relatively long list is why I'm not so happy with only the approach of feature_* or feature_bug_*_fixed. I'm wondering how you would decide which bugs/features get they're only variable and which ones not? The list would get quite long soon, if you're not very restrictive. From my point of view most users are using the (recommended) default methods to boot our LiveCD, which involves somehow loading the core.img usually as linux image. In that case the version of grub is predictable. The few other users should just get a graceful failure message that they're version is too old, if it is. This gives them the chance to install a newer version or boot the LiveCD differently. I don't care if I accidentally hit some backported bugfix, which is not common among Slackware anyway, and it would actually work, because all those feature checking is hard to maintain and one (me or the backporter) could easily miss something. In the latter case users wouldn't get a graceful failure anymore and would come back unhappy and complaining, while there could have been a simple message that tells them what to do and that the problem is their setup. That way we can even give them a comparably rudimentary menu to boot the LiveCD. Therefor I prefer hitting few users accidentally with a version check instead of failing non-gracefully for some. After all a check for the version would be easy to remove, while multiple feature checks aren't. Sometimes it's just easier and thus less error-prone to draw a clear line. Especially as workarounds for backwards support can become very big or almost whole rewrites. That's when to draw a line in my opinion and that's the case with 1.98 at least for us. On the other hand when looking at the usage of the feature variables in 2.00 I see that it's a much better solution in that case. > Then > if [ x$feature_bug_XYZ = xy ]; then > > else > > fi > >> Did those feature variables even exist in 1.99? > They didn't but a missing variable is expanded to empty string so this > check works exactly as intended >> Maybe something like a grub_version_min command? And possibly *_max? >> > I don't see why you need it when you can check for features directly. > Distros often distribute older versions but with backported bugfixes and > check for exact features is better.