On Fri, Oct 7, 2016 at 8:01 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > 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. You're focusing on the technical aspects of the implementations. I was making a subtle point about the fact that any Fedora-specific version of a spec will simply remain a Fedora specific version, which defeats the purpose of a specification to begin with. In essence, we'll wind up repeating the implied lesson of grubby. If we're going to work on a specification, it should be done in coordination with other distros. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
