On 17 June 2012 18:49, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > You're asserting that dbus-daemon etc cannot be restarted, but without > saying why. Okay, I'll say why. The core protocol was never designed to support the dbus-daemon being restarted. > The current design may make restarting some daemons > difficult but we should fix those problems. So, to install a zlib update, according to your proposal we now have to QA the effects of restarting several per-system userspace daemons at runtime (which may be disabled or enabled depending on the specific user config) and also have to test the session clients (of all three desktops) code support when core system services disappear and then (hopefully) reappear a few seconds later. And make sure that this works for multi-user logins and fast-user switching. And we hope that the updates have not failed to be installed leaving the session without core stuff like gnome-session and dbus. So then we try to roll back to the previous system state using snapshotting, even though the non-idle system has already written other normal stuff to /usr and /etc which we mistakenly revert... See how crazy this sounds? Please trust me when I say we've thought about this stuff quite a lot, and the only sane way to do this was wither with a recovery partition or a minimal boot environment like I've suggested. It's a miracle the stuff we try to QA now works at all. > - QNX > - z/VM > - EROS Have you got an example of any popular desktop OS? > It might not be possible *with poorly designed Linux > daemons* but that's quite a different thing. As the maintainer of a few of the aforementioned "poorly designed Linux daemons" I can tell you that's simply not possible. I'm sure you appreciate how complicated restarting a service without dropping state would be with your work with libvirtd. Richard. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel