The hard problem of live major release upgrades

I've held forth before on things that boil down to 'it would be really nice if my favorite Linux distribution had live release upgrades'.

One might think that this is an easy feature to add. After all, in a modern Linux an upgrade from one release to the next mostly consists of updating a huge number of packages, and everyone has excellent, very well tested support for doing that. So, just change things to get packages from the new release's repository and do a regular package update and you're mostly done, right?

(This is in fact what the Fedora yum-based upgrade method basically boils down to.)

But doing this reliably is actually a hard problem. There are a number of smaller issues, but the big issue is dependency chains for package updates combined with the need to keep things working on the running system. Consider a hypothetical situation: standard shell utilies use the new version of glibc (of course), the new version of glibc requires a new version of the kernel that supports new APIs that it's using, and of course, installing the new kernel requires a reboot. So much for your live upgrade.

The inevitable conclusion is that to make live upgrades work, you need at least core system components to be backwards compatible for at least one release. What counts as a 'core system component' here is one of those somewhat hard problems, and in general this is a constraint that developers may not be too happy about.

(It's also worth noting that backwards compatibility can be very hard to test thoroughly, and it's very easy for hidden dependencies to creep in.)

The smaller issues that I see are not insignificant either:

• not all system changes done during upgrades are just package updates; your live release upgrade is going to have to be more than just a bunch of package updates.

• sometimes packages are rearranged, split, renamed, and so on between releases in ways that the normal package manager can't handle (or at least not handle safely).

  (Fedora has traditionally handled this by running package updates in an unsafe 'overwrite everything' mode during release upgrades and hard coding a list of packages that need special handling.)

All of these problems are drastically simplified by being done from 'outside' of the system being upgraded, as happens during a non-live release upgrade. When you're working outside, you don't have to keep the system running during the whole process and as a result can do relatively violent changes. You also don't have to use the usual package update tools, tools that are explicitly designed to avoid horrible accidents during normal upgrades and package installations.