I think this is growing severely overengineered. It is already more
complex than it needs to be.
The scripts in /etc/grub.d *are* config files. There's no reason you
can't edit them to suit your needs.
I agree that my solution does seem rather overengineered.
My problem is that while /etc/grub.d/* may be config files in some
technical sense, they don't behave like them. In particular for most
config files, changes you make are largely "orthogonal" to the rest of
the file whereas my changes to /etc/grub.d are mixed in with complex
logic which I have no interest in changing. Combined with frequent
changes to the default version of the file, this makes merging new
versions a burden.
My patch reduces the configuration needed to set up variant command
lines to a few lines in /etc/default/grub, which are indeed orthogonal
to the rest of the file.
To solve this exact problem I distribute my own grub.d/01_custom_entries and
grub.d/40_custom_vars hooks on my systems. They rely on a ruby script that globs
/boot/vmlinu* (and other operating systems kernels) and builds a hash of
entries for every kernel and for all the variants of the command line I want
or need on the systems. Because the entries come first, I can just
index-count _my_ menu items and know they'll always be "first" and because
the vars hook is at the end of the mkconfig run, I can "set default=3" from
there and know it won't be overruled by the stock hooks.
The fact is that this patch would make it seem weird that none of the
_other_ kernel types in grub.d will have variants either. Leading to a
proliferation of GRUB_FOOBAROS_VARIANTS= in /etc/default/grub. Bourne
shell is simply the wrong language for this kind of thing (no
hashes/dictonaries/multi-dimensional-arrays) but it's all that can be
demanded by any OS to support grub-mkconfig.
IMHO, the default mkconfig stuff shipped with grub should be considered a
reference implementation that can be kept simple and working on all
distros _of_ all OS's but its certainly not the only way to generate a good
config for your site. Patching the stock system to your specific needs might
make less burden for you now but more for everyone else down the road.
-joey
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
