Proposed F19 Feature: Fedora Upgrade - using yum

[Przemek Klosowski]

On 01/24/2013 06:12 PM, Lennart Poettering wrote:
> If you restart any of those you bring down the entire machine basically,
> or bring down at least the bits you really want to avoid, i.e. the
> user's sessions...
>
> Then all code that runs that is not a system service is difficult to
> restart from a system script. How do you plan to restart Evolution or
> Firefox, or Gimp?
...
> Of course, you could tell the user as last step of your script to
> "please reboot now", but if you do that your update isn't "online"
> anymore, but is awfully close to real offline upgrades, except that
> during the upgrade period you have a ton of processes around that might
> be seriously confused by not being able to find their own resources
> anymore or in wrong versions...

This is a pessimistic view but I think it's not as intractable.

There are two separate aspects to it: discovery what needs to be 
restarted, and the actual process of restarting. The discovery is almost 
there: we know the resources (libs, files, etc) that were replaced, so 
it's a matter of walking the list of running processes and checking if 
they depend on those resources. I can see how transient I/O, including 
dlopen() could be tricky, but I don't think it's fundamentally 
impossible---at worst, it'd be implementing some sort of 
/proc/1234/history-of-opened-fd mechanism.

That leaves the restarting: again it seems to me that is not as hopeless 
as you make it sound, either: kernel is hardest but even there people 
are working on ksplice. Many services are designed to be restarted, like 
DHCPD which doesn't even have an online reload but has to be bounced if 
the DHCP data file changes.

Regular process restart is of course application dependent,  but e.g. 
Firefox actually restarts relatively graciously: I just killed mine and 
the new instance reopened all my tabs (a pleasant surprise--I expected 
the Restore Session ("Well this is embarrassing") window I was used to). 
Maybe there is a couple of classes that the restart falls into:

- no problems restarting anytime

- availability problems but no data loss on restart (easy restart but 
maybe needs user confirmation)

- some out-of-process support needed (file rotation/cleanup, etc)

- user intervention required (saving files, etc).


I believe that seamless upgrades are an attractive goal. I am not 
arguing for infinite upgrades---only a fresh install can guarantee 
getting all new technologies that one wouldn't get through upgrades 
because they may not even existed at the original installation. My point 
is that the reinstall decision should be in principle driven by the 
user, not by the OS release schedule.