All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Grub version variable in shell
Date: Sun, 11 Mar 2012 13:47:11 +0100	[thread overview]
Message-ID: <4F5C9ECF.5010707@gmail.com> (raw)
In-Reply-To: <4F5C920D.7070808@googlemail.com>

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

On 11.03.2012 12:52, Andreas Born wrote:
> Am 11.03.2012 03:51, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> On 11.03.2012 03:40, Andreas Born wrote:
>>> Hi,
>>>
>>> it would be great to have a variable like version or grub_version in
>>> the shell. Sorry, if there is already such an option and I didn't find
>>> it. But I only saw cpu and platform as well as the feature variables.
>>>
>>> This is useful, if you want to use some new feature or don't want to
>>> use some ugly workaround anymore, which you needed for an older
>>> version.
>> We don't use grub_version because it would give only very approximate
>> idea of features supported and so only marginally useful and is likely
>> to make devs use suboptimal method. Instead we define variables like
>> feature_foo. Good example is from root setting code:
>> if [ x$feature_platform_search_hint = xy ]; then
>>    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt10
>> --hint-efi=hd0,gpt10 --hint-baremetal=ahci0,gpt10  UUID
>> else
>>    search --no-floppy --fs-uuid --set=root UUID
>> fi
> Thank you, I get your point.
> Still I think version can be useful to exclude versions with bugs (or
> features) they do/(don't) have. For example on 1.98 I had to reexport
> all variables in every configfile. This was dirty and hard to maintain
> so I do not want to maintain this anymore. Instead of silently
> failing, I'd like to provide users of older versions with a very
> simple menu combined with a warning. (Usually in normal boot scenarios
> they're using my grub build anyway.) I don't see how this should be
> possible without my 'if keymap' hack. I think neither checking for a
> command existence nor a feature is a reliable method to always ensure
> a minimum version. Of course if you have a better idea, that's even
> more welcome.
Why not define "feature_bugXYZ_fixed" for bugs?
Which ones are missing in 2.00~beta1?
Then
if [ x$feature_bug_XYZ = xy ]; then
   <normal version>
else
   <bug-workaround version>
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.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

  reply	other threads:[~2012-03-11 12:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-11  2:40 Grub version variable in shell Andreas Born
2012-03-11  2:51 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 11:52   ` Andreas Born
2012-03-11 12:47     ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2012-03-11 13:55       ` Andreas Born
2012-03-11 14:07         ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 14:17           ` Andreas Born
2012-03-11 14:20             ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 14:58               ` Andreas Vogel
2012-03-11 21:13                 ` Seth Goldberg
2012-03-11 12:52     ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-03-11 14:39       ` Andreas Vogel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F5C9ECF.5010707@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.