Re: Grub version variable in shell

[Andreas Born <futur.andy@googlemail.com>]

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
>     <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.