On Mon, Jun 18, 2018 at 03:29:34PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jun 18, 2018 at 11:17:50AM -0400, Peter Jones wrote:
> > On Thu, Jun 14, 2018 at 12:40:50PM -0700, Adam Williamson wrote:
> > > On Thu, 2018-06-14 at 15:10 -0400, Matthew Miller wrote:
> > > > On Thu, Jun 14, 2018 at 11:51:33AM -0700, Adam Williamson wrote:
> > > > > > ** Have a grubby wrapper for backward compatbility that manipulates BLS files.
> > > > >
> > > > > What exactly is the plan for upgrades, here?
> > > >
> > > > I *assume* it's what the "grubby wrapper" is there for?
> > >
> > > Yeah, I was hoping for more details :)
> >
> > The grubby wrapper is actually to provide a transition plan to external
> > scripts and tools that are using grubby, but which we're not aware of.
>
> I wonder if this providing the compat interface is worth the trouble.
> If there are those external scripts and tools, it's impossible to know
> that they still work with the replacement, unless the replacement
> implements everything *exactly* as the original, but that's pretty
> much impossible considering that the new scheme is so much different.
I think that's a valid point, but we've already written it, so I don't
think it's going to have a big practical impact to viability at this
point. And since it doesn't need to do parse and re-write the actual
grub.cfg[0], it is relatively small and straightforward, so most changes
are either creating or removing a bls file or grub2-editenv. Primarily
this exists to provide functionality like querying "what kernel will I
boot next?" or setting "boot $FOO next".
> So maybe it'd be both less work *and* safer, to just keep grubby as is,
> allow existing installations to continue using grubby, and switch
> all new installations to not use it at all and not even install it there?
There's literally no plan to change anything about how the grubby that
exists works aside from eventually dead-packaging it.
> F29 is not that far out actually, and I think it'd be better to devote
> available resource to the new implementation, instead of any compat
> measures.
That's true - though we actually shipped nearly all of the code to
implement this stuff f28, minus some parts of the upgrade story and the
anaconda bits to enable it by default. You can go run
grub2-switch-to-blscfg today, and it will work. I hope :)
[0] we do run sed on zipl.conf to change default= on that platform,
because they don't have a concept like the grub environment file.
--
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/B4IDUWX66K3U2E4D7XFAHSVHTYZS6M35/
