On Tue, Jun 26, 2018 at 03:46:59PM +0200, Javier Martinez Canillas wrote:
> That raises two questions:
> 1. Why isn't just the bls-snippet filename used as the key? It's
> necessarily unique and should be usable for the purpose of uniquely
> identifying the boot entry without creating a separate field.
I'll let Peter answer this question since he wrote the grub2
implementation. Doing this will be pretty trivial, but in that case we
should also sort using the filenames if the id field isn't defined.
I don't know that I have a specific reason in mind when I wrote that bit
of code. Most likely the real answer is: because when I realized we
have to sort them, I was writing parser code not directory iterating
code.
Waaaaay back when the config files were on VFAT on UEFI machines, it
also meant I didn't have to even worry about the (entirely likely)
situation arising where I have to re-implement this with some other API
where I don't know if I'm going to get long filenames or not.
For me, having it in the file seems more natural while I'm staring at
the file with my eyes, since that's where I'm reading other values used
in the same context. But I see the point being made as well. Maybe the
thing to do here is prefer "id" if it's in the file, but use the
filename if it isn't, and to disambiguate collisions.
This is already the case for Petitboot since the maintainer asked
for
the filename to be used as the key as well. For zipl the key is the
version field because currently the kernel version is used as the
zipl.conf section name and the maintainer wanted to keep the same
behavior with BLS.
Does this effectively mean we just have a different resolution order
there? Like are we comparing id and linux if version collides, or just
not using them?
Sorting using the filename won't work with ostree though. The
BLS
snippets are named ostree-$ID-$VARIANT_ID-$index.conf but the entries
are sorted using the version field, and the index is the inverse of
the version.
One option is to change ostree so the BLS snippets are named
ostree-$ID-$VARIANT_ID-$version.conf, but I don't know if there's a
reason to have the index there. Another option is to give more
precedence to the version field and only sort using the filenames if
neither the id nor the version fields are defined.
> 2. Why is "id" supposed to be sortable? What sorting would grub2 do
> with it?
It's sortable so grub2 can display the boot menu entries in the
correct order. This is also answered in the Changes page:
id - provides us with a sort key, sorted using rpm's version
comparison function. Generally of the form:
fedora-20180530145228-4.16.13-300.fc28.x86_64
Put another way: if you don't have a saved_entry set in grub.cfg, or if
it's saved_entry=0, if we don't have a sort field then you're going to
get whatever comes out of your filesystem's directory storage algorithm
first. Sometimes that's a linked-list that may or may not be sorted,
sometimes it's a b+tree, sometimes it's a hash bucket. It's kind of
hard to think anyone wants that behavior.
It attempts to sort using the id field, and if this isn't
defined
other fields are used as fallback in the following order: version,
title, linux.
Yeah, so maybe we want to make that:
version, id, <config file name>, title, linux
So that it can be the same everywhere. Aside from cases where it'll be
confusing if all the values just arbitrarily don't match each other
(just don't do that unless you want to confuse yourself), is there some
case I'm missing where that makes it worse?
--
Peter