Re: F29 System Wide Change: Make BootLoaderSpec the default ['id' field]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/Z2BYMCTDTE7YIIF7CSROPT22E24ZCNYL/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux