On Sat, Oct 8, 2016 at 5:24 AM, Josh Boyer <jwbo...@fedoraproject.org> wrote: > On Fri, Oct 7, 2016 at 8:01 PM, Andrew Lutomirski <l...@mit.edu> wrote: >> On Fri, Oct 7, 2016 at 4:55 PM, Josh Boyer <jwbo...@fedoraproject.org> wrote: >>> On Fri, Oct 7, 2016 at 5:14 PM, Chris Murphy <li...@colorremedies.com> >>> 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 <ke...@scrye.com> 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.
My idea of a spec was just to document what Fedora needs to support, so it's known what work needs to be done, including documentation. That is, start with what we're actually willing to do, rather than some fiction we won't even follow anyway. Of the two bootloader specs, we don't exactly follow either one of them, in meaningful ways: Like where the configuration files live, which is a fundamental point of those specs. If GRUB upstream code is an implicit spec, we don't follow that either. Fedora's GRUB puts the bootloader config file in a different location depending on the firmware being used; upstream and other distros don't do that. And Fedora's GRUB uses kernel and initrd commands that upstream does not use, nor any other distro I've looked at, and therefore our GRUB is unable to use other distro's grub.cfgs. When it comes to discovery of other OS's our installer team rejects the idea they're supposed to activate all LVM LV's so os-prober can discover those OS's. Fedora is divergent. Even if there were coordination done with other distros on a spec, why would we suddenly start following that one? Anyway, coordination has been tried and failed. Whether the distros just don't care about the problem, or actually enjoy the mutual incompatibility, I can't say. But in the end it's gone no where. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
