On Wed, 2007-01-03 at 21:42 +0000, David Woodhouse wrote: > On Wed, 2007-01-03 at 16:31 -0500, Jeremy Katz wrote: > > On Thu, 2007-01-04 at 01:42 +0530, Rahul Sundaram wrote: > > > Pup should notify users when the release they are using reaches end of > > > life as well as availability of new releases and the live upgrade tool > > > should be hooked into pup. For the next release, we might maintain it as > > > a experimental feature and stabilize this as we have move forward. There > > > are some cases where a live upgrade wont work efficiently but for > > > majority of use cases the only reason live upgrades dont work properly > > > are real packaging problems which we should be fixing anyway. > > > > Sadly, this isn't actually the case. The number of "weird" cases that > > are just "remove this package" is far smaller than the other bizarre > > bits that have caused live upgrades to not work reliably. > > That's not my experience. Live upgrades have worked fine for me ever > since about RHL5. I can generally get them to work as well. But there are weird cases that have been dealt with over time; sure they're work-aroundable if you're pretty saavy. It's not, though, the experience that most users want. Live upgrades can also lead to "really interesting" states if you, say, unplug your machine in the middle[1]. For a quick list of "off the top of my head weird problem" examples: * Going from static /dev -> udev involved some interesting shenanigans to avoid all of your devices disappearing mid-upgrade. * Newer SELinux policy depending on a kernel supporting that policy version. * glibc being built with a dependency on newer kernels for some new feature * New rpm functionality used by packages requiring a new version of rpm to install them The number of releases where there is one of these sorts of things is higher than the number where we don't have them. > Sometimes there's a glitch which you need to deal with manually (like > having to reformat swap space for 64KiB pages), but stuff like that > happens even with "installer" upgrades too. The key being that for these "manual" things, anaconda can and *DOES* take care of them[2]. At least, for the cases where people have tested upgrades over test releases and noticed a problem Jeremy [1] Yes, this isn't "good" if it happens when they're upgrading via anaconda also, but they are at least more likely to be able to boot back to anaconda and be able to, at the very least, reinstall, if not restart the upgrade and have things come out mostly okay. [2] Support for this specific case is in anaconda now _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly