On Fri, Oct 7, 2016 at 4:55 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Fri, Oct 7, 2016 at 5:14 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> Changed this subject to match the other one I changed, so if I'm doing >> it wrong at least I'm consistent! >> >> On Fri, Oct 7, 2016 at 9:22 AM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: >>> So, I think we would need to get buyin to get our changes into the spec >>> and get everyone to agree on it before we would want to move to it. >> >> The original spec is unworkable. And attempts to expand the upstream >> spec for real world use cases needed in Fedora haven't gone anywhere. >> It exchanges reduced complexity in the bootloader, by increasing it in >> the installer and increasing wasted space on the drive. I'd try to >> help make it salvageable but I think it's pointless. Make a Fedora >> specific version and if people like it they can adopt it. > > Which, in effect, could just as well be writing a "specification" for grubby. I disagree. The bootloader spec, update-grub, and pretty much everything except grubby are stateless in the sense that the list of installed kernels and other things is generated freshly each time it updates. (The bootloader spec does this at every boot, and update-grub does it whenever it's run.) These solutions don't try to let users customize the result after the fact. Instead, any customization is written to a file intended for the specific purpose of customizing the boot process, and that file is never written by automatic tools. Bootloader spec parsing, update-grub, etc are all idempotent, which is a *really* nice property. Grubby attempts to parse a configuration file and apply a change for a single kernel addition or removal to it without losing other customizations. This is a much harder problem to solve well. It's also not idempotent. Unsurprisingly (to me, anyway), it doesn't seem to work all that well and it's a PITA to maintain. --Andy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
