Proposed F19 Feature: Fedora Upgrade - using yum

[kaperang07 at gmail.com]

> 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.
> 
> 
> 
> -- 
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130125/2fb91849/attachment-0001.html>