Re: Breakage from grub-mkconfig changes for grub-file

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 23.12.2013 23:01, Colin Watson wrote:
> 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.)
> 
The idea was that platform-independent scripts were still runnable,
they'll just produce the same output N times and this list is just an
optimisations, specially to avoid running os-prober N times.
The alternative will be to have something along the lines of different
hashbang or implementing this functionality as sh functions.
>   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.
> 
GRUB platform names don't match with the OS compatibility. On x86 other
than xen you can use the same kernel on all the platforms. On ARM, for
what is arm-uboot platform for us may require different kernels for
different hardware.
>   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.
> 
Ok.
>   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.
> 
Nice catch.

> 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?
I think it's good to move it to "next", together with --root-directory
functionality of grub-mkconfig.
Paulo Flabiano Smorigo wanted this feature badly. Unless he has striking
arguments why 2.02 needs it, I'm ok with moving this to "next".

signature.asc
Description: OpenPGP digital signature