[PATCH 4/6] bootloader/payload: Add Payload.handlesBootloaderConfiguration() boolean

Vratislav Podzimek vpodzime at redhat.com
Wed Apr 30 07:09:10 UTC 2014


On Tue, 2014-04-29 at 13:38 +0000, Colin Walters wrote:
> On Tue, Apr 29, 2014 at 8:13 AM, Vratislav Podzimek
> <vpodzime at redhat.com> wrote:
> > That doesn't mean that every payload handling boot loader
> > configuration works the same way.
> 
> True, but at the moment we're talking theory - there are no other
> payloads that handleBootloaderConfiguration.  Is anyone aware of one
> that might be forthcoming?
> 
> 
> I could imagine some variant of TarPayload that would (e.g. you just
> want to write out a static copy of /boot/extlinux.conf directly), but
> in my opinion OSTree is significantly better than tar in pretty much
> every way for operating system deployment.  You get built-in online
> incremental upgrades, *fully atomic* upgrades, rollback, /usr is
> mounted readonly (even while upgrading), the git-like versioned
> storage on the server side, etc.
Still, that doesn't mean there won't be anything better/different in the
future. From what comes to my mind now --  one could for example
distribute XFS fs snaphots or LV snapshots or whatsoever. If you want to
have the class somehow abstract and versatile you cannot fit it to one
particular case. Otherwise you could name the property "isOSTree" and
make it's meaning more obvious.

> 
> 
> That all said if you feel strongly I can create a new boolean prop
> "requiresSysconfigKernel" or something on Payload, but it feels to me
> like we can just leave this issue for any later Payload subclass
> implementors.  Or better, push back and improve either packages or
> ostree payloads to cover the use case.
Providing API (which a definition of the superclass, more so an abstract
one, is) doesn't really go well with "it feels to me like we can just
leave this issue for any later Payload subclass implementors".

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list