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/
