On Wed, Nov 8, 2017, at 12:36 PM, Dusty Mabe wrote: > > > On 11/08/2017 12:06 PM, Colin Walters wrote: > > On Wed, Nov 8, 2017, at 11:33 AM, Dusty Mabe wrote: > >> > >> - ostree admin unlock --hotfix > >> - alias yum='/usr/share/yum-cli/yummain.py' > > > > Let's please not mention `--hotfix`? > > So the more official answer is: use traditional CentOS
IMO, yep! This type of thing is a lot of the reason why we need two models for a while. But just diving into this a bit - while we haven't yet plumbed through automatic updates into rpm-ostree by default yet, we finally added `rpm-ostree upgrade --download-only` which does a *lot* of this. And I'd really like to flesh out the background/automatic updates story more and get to where we can turn it on by default. Yet things like dkms have a lot of hooks into system updates. I just looked at the implementation slightly more closely and it actually forks off a daemon helper right in the middle of a traditional yum update. One of the promises we'd make once we enable background host updates by default is that they *don't touch* your running OS; we wouldn't try to reload kernel modules for example if we picked up a newer nvidia driver RPM. This conflicts directly with the traditional yum/apt model of trying to apply updates live, and I think things get really interesting here with dkms as of course the kernel isn't updated live, but other bits of userspace like the "kernel-devel" is. Oh, and another big thing is that our upgrades are *cancellable*, you can Ctrl-C them at any time. This ties in with the "background" story - if we have automatic updates enabled, you still want `rpm-ostree install` to preempt that. If DKMS is going off and starting its own systemd service making changes that's going to be way harder. How hard would it be to make dkms play nicely with this? I don't honestly know.
