Re: [RESEND RESEND RESEND PATCH] templates: introduce GRUB_TOP_LEVEL_* vars

[Denton Liu]

Thanks for the response, Oskari!

On Thu, Sep 29, 2022 at 01:08:03AM -0500, Oskari Pirhonen wrote:
> On Tue, Sep 27, 2022 at 05:30:45 -0700, Denton Liu wrote:
> > A user may wish to use an image that is not sorted as the "latest"
> > version as the top-level entry. For example, in Arch Linux, if a user
> > has the LTS and regular kernels installed, `/boot/vmlinuz-linux-lts`
> > gets sorted as the "latest" compared to `/boot/vmlinuz-linux`. However,
> > a user may wish to use the regular kernel as the default with the LTS
> > only existing as a backup.
> > 
> > Introduce the GRUB_TOP_LEVEL_LINUX and GRUB_TOP_LEVEL_XEN variables to
> > allow users to specify the top-level entry.
> > 
> 
> A couple questions:
> 
> - If all you're looking for is /boot/vmlinuz-linux to be booted, is
>   setting GRUB_DEFAULT in /etc/default/grub "good enough" for your use
>   case?

I think it is "good enough" for what I need but it feels a little bit
weird that grub doesn't give the user any choice as to what the
top-level kernel is.

> - Is it possible to make this solution more universal? Maybe BSD users
>   would like to set their top level entry.

I'm not too familiar with what end-users might want. If we want to make
this more universal, we could either do GRUB_TOP_LEVEL_KERNEL and have
that shared amongst all of the 10_* files or we could have multiple
variables, e.g. GRUB_TOP_LEVEL_LINUX, GRUB_TOP_LEVEL_BSD, etc.

> - What about for os-prober? My understanding is that it creates its own
>   top level entries as well.

The same thing could work with os-prober, although it wouldn't be a
cut-and-paste.

I'm open to all ideas here and I can cook up the patches. The thing is
that I'm not sure what the project's conventions are regarding
too-granular/not-granular-enough configurations so some advice here
would be very much appreciated!

-Denton