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

Colin Walters walters at verbum.org
Wed Apr 30 20:20:13 UTC 2014


On Wed, Apr 30, 2014 at 3:09 AM, Vratislav Podzimek 
<vpodzime at redhat.com> wrote:

> 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.

Sure, one case some people were talking about is using "btrfs send" for 
OS updates.

I think what these people don't realize is while a large component of 
operating system updates is just getting data from A to B (relatively 
efficiently), there are really a lot of other things that need to 
happen.  For example, you need some code that handles the bootloader 
configuration (what we're talking about here).  And you need tooling 
around things like GPG verification, TLS certificates, etc.

OSTree also has special handling for /etc to perserve configuration 
while also giving you new config files.

And rpm-ostree takes this a whole step farther by linking to 
librpm/hawkey and doing a *package* level diff of the two RPM databases 
in the two trees - something still important for sysadmins.    See:
http://fedorapeople.org/~walters/project-atomic-package-diff.png
(For a demo update, I removed tmux and added screen)

And even better, it will have the capability to layer packages on top, 
which is pretty essential to make the whole thing practical.

Finally, Linux storage is such a wide world that I think there's a 
really strong case for update systems remaining storage independent (as 
rpm and OSTree are).  Locking yourself into XFS, BTRFS, LVM or whatever 
greatly decreases the flexibility available to client systems.    That 
said at least for OSTree I plan to aggressively take advantage of any 
optional APIs offered by the storage layer.   I'm hoping for open(..., 
O_OBJECT).

>  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.

I can do something that if you think that's best, but based on the 
above I think there's a pretty strong argument against adding further 
payload types.  Further if anyone *did* add any other payload types 
that weren't yum/dnf, it seems highly likely to me they wouldn't want 
/etc/sysconfig/kernel either.  Right?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/anaconda-patches/attachments/20140430/7dc4564c/attachment.html>


More information about the anaconda-patches mailing list