On Tue, Sep 29, 2009 at 6:12 PM, Bill Nottingham <notting@redhat.com> wrote:

This means that for me on rawhide, my session is often much longer-lived than my
software set, as I'll have a two-week session that is running older code
that I've long since upgraded past. Even for those on an actual release,
this can be an issue given our update stream.

Note we should optimize the system for the main release, not rawhide.  Not that a good rawhide experience isn't useful, but it's a rather extreme case.

For system-level services, we have the idea of try-restart on upgrades; if
the service is running, we automatically restart it on upgrade.

How does that work?  Obviously you can't restart packagekitd while it's in the middle of upgrading.  Another one you obviously can't just kill and restart is libvirtd.
 
How can
we implement this sanely for session/desktop services? For example, in
my session I see:
 
I think this ends up being a case by case thing.  If someone wants to implement things so that a live upgrade works, that's all well and good.  The default state though must be reliable; so any generic mechanism that kills processes blindly is just not going to work.

If someone wanted to work on this, packagekit may already have a signal for when things are upgraded, and it could make sense to just listen to that.

The live replace files on disk part of upgrade is also problematic, and is actually the most broken thing relating to updates we have right now.  For this reason among others I think we should move to installing updates immediately before logout/reboot.