[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grub version variable in shell

From: Andreas Born
Subject: Re: Grub version variable in shell
Date: Sun, 11 Mar 2012 14:55:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120220 Thunderbird/10.0.2

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.

if [ x$feature_bug_XYZ = xy ]; then
    <normal version>
    <bug-workaround version>

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]