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

[pfsmorigo]

Mon, Dec 23, 2013 at 11:21:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> 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".
> 

We can move this to next. The --root-directory is not high priority
and can delay it without problems.

> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel