[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