ec824e0f2a399ce2ab3a2e3353d372a236595059 introduced extensive changes to grub-mkconfig, which among other things arranged to run all but a hardcoded list of grub.d scripts once for each of several platforms with their output enclosed in an "if" block. I do not feel that this change was well-thought-out, and I think it should be rethought or reverted before 2.02. I didn't see anything about it here in advance - did I miss a thread?
The problems I have with it are illustrated by its effects on the Debian patch. I must emphasise that I don't think this is unique to the case of distributions with non-trivial patch sets, and that it's also likely to affect users who have made reasonable changes to /etc/grub.d/ locally (as they're entitled to do); distributions are just a useful early-warning system here. 1) Awkward hardcoded list; poor configurability 00_header, 30_os-prober, 40_custom, and 41_custom are run only once. The Debian patch set has an additional script which is not platform-dependent and should be run only once, namely 05_debian_theme, so I had to add another case here. Users will surely have other such files; not only do they have to know on upgrade that they need to take care of this, but they have no recourse that doesn't involve editing $prefix/bin/grub-mkconfig, which is not a file that should normally be edited by the system administrator; changes to that file will not normally persist on upgrades. This should be redesigned so that there is some way to declare in a grub.d script that it requires multi-platform support and should be run multiple times. (It *must* be this way round so that upgrades work properly.) 2) Strange ad-hoc platform names The platform names used in grub-mkconfig (x86 i386-xen-pae x86_64-xen mips mipsel sparc64 powerpc ia64 arm arm64) are not the same as the platform names used in the GRUB build system, but yet they're exported across the interface to /etc/grub.d/ as GRUB_PLATFORM. This is messy and confusing, and it's not clear what promises we make about future changes here. We should rationalise this before issuing anything as part of a stable release, perhaps by adopting the same target_cpu/platform terminology used in the build system. Furthermore, if we made the namespaces match up then it would be fairly straightforward to only run grub.d scripts for platforms for which we have installed GRUB modules, which seems as though it would be sensible. 3) Breaks function definitions In the GRUB script language, "function" is only permitted at the top level. This may be an oversight since bash doesn't share this restriction and GRUB script generally tries to look like bash; nevertheless it exists today. Part of the Debian patch set causes 10_linux to emit a function definition, which now causes a syntax error. I think my preferred fix here would be to implement functions other than at the top level, but it seems a bit rash to try to cram that into 2.02. 4) Smaller bugs Aside from the bug fixed in 77ec462a568fc9c89ef45e960bf33b5de73140fb, I'm pretty sure that the condition for the "x86" platform is buggy; shouldn't it have an extra "-a" in there? This sort of thing makes me worried about the level of testing these changes have had. The grub-file tool seems reasonable and useful to me, but can we just revert the grub-mkconfig parts of these changes until after 2.02 so that the effects of these interface changes can be considered more carefully? It looks like it was part of a new feature rather than a bug-fix. I noticed this while testing Debian packages of 2.02~beta1. Unfortunately, I don't think I can salvage this into something I can upload without extensive interface changes of the sort that I'm not comfortable making downstream. Thanks, -- Colin Watson [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
