PainlessUpgrade

Summary

Allowing users to upgrade an existing system and end with a system similar to a fresh installation of the new release.

Rationale

Upgrading a fresh Ubuntu x to Ubuntu x+1 doesn't give you the same system as installing directly a fresh x+1. This lead to having systems that are, at each release, a bit more far from the current release, with unexpected bugs that cannot be reproduced easily.

Ironically, most advanced Ubuntu users now reinstall their system every 6 months; that was what we were laughing at about Windows...

This spec adress this issue by proposing a real dist-upgrade mode which would allow you to fully upgrade your system, with more interactions than the simple dist-upgrade.

This spec doesn't not intend to provide the same "painless upgrade" functionalities for beta-testers that are using pre-release, but it could be a nice side effect.

Use Cases

  • Melissa installed Ubuntu LTS 6.06 then upgraded to 6.10 then to 7.04. She doesn't want to reinstall her system but still have a nice 7.10 nearly-default desktop.
  • Dennis has customized a lot his Ubuntu installation. As he's running out of disk space after an dist-upgrade, he believes he can uninstall package that were part of the default previous installation and that are no longer required. Deborphan and autoremove does'nt help him very much here.
  • In order to report bugs with accuracy, Jono does a fresh install with each Ubuntu release. But he would really like dismiss those hours of reinstalling then reconfiguring then re-apt-getting all packages he needs.
  • Lionel wanted to install Edgy on his new laptop but has only one Dapper CD. So he installed Dapper then dist-upgraded it directly to Edgy. But his dual core pentium shows only has a single core. After looking on Internet, he found that default edgy kernel is not the same as the default dapper kernel, which one the was he was using even after dist-upgrade. He wonders how many things like that he missed by installing dapper instead of edgy...
  • Sonny's son manually configurer his network interfaces in /etc/network/intefaces. Now that he upgraded to Feisty, Sonny want to enjoy network-manager. Unfortunatly, his son is away for a few months and he doesn't understand why he cannot simply use Network-Manager, just like he does on a freshly installed Feisty.

Scope

This specification covers feature specifications for Ubuntu. Affected applications could range from apt to synaptic or simply affect a new dedicated front-end to apt with new meta-packages.

Design

A proposed implementation could be an upgrading tool that would show you following things :

  • Packages that are part of the default previous install and are still in the current one. Will be straightforwardly upgraded
  • Packages that were part of the default previous install and are not longer anymore. Must be deleted after confirmation.
  • Packages that were not part of the default install and are now part of it. Will be installed.
  • Packages that you have manually installed that are not longer in the new repository. Must be deleted after confirmation.
  • Things that were manually added in stuffs like /usr/local or /opt (think "compiled softwares" or third party apps)

Also, this interface will shows you a list of change that were made in the configuration files. It will allow you to select which one must be kept and which one must be set to the default config. This behaviour already exists in apt during the upgrade process but it could be good to have it outside this process so you can see it at anytime and easily revert to a default config.

A special "real upgrade as a fresh install mode" will allow you to automatically upgrade and have exactly the system you would have by doing a fresh install and apt-getting the packages you want.

It would also help to have a list of packages you actually installed (with apt-get, synaptic or add/remove) regardless of all the dependencies. Because the system can assume that those are the packages you really want. Such a list is already maintained for auto-remove, it would help to be allowed to see this list.

Implementation

Currently, the autoremove feature in apt could be considerer as part of the solution.

Outstanding Issues

BoF agenda and discussion

What about something that culls old version of packages in /var/cache/apt/archives? I just went through and deleted all but the two newest (in case I have to downgrade everything), but since I'm running Feisty there were sometimes 8 or 10 versions of a package. After upgrading from Breezy to Dapper to Edgy to Feisty (with them all being stable, not doing the unstable thing at all), I can image the cache would be in even worse shape and taking up a lot more space than necessary. Mackenzie

Warbo: I think this would work best if the update manager (or wherever this functionality is implemented) can give a list of outstanding upgrade issues which the user has yet to test that pops up every now and again from the notification area. For instance a list might be "Network functioning correctly", "3D graphics enabled", "Extra pointing device functioning correctly" if the system has custom networking and Xorg config files. When the user gets around to testing these functions they can answer yes or no to keep or overwrite their config files respectively. Where yes is given the issue is taken off the list. Where no is given the issue is put back on the list to try again with the overwritten config (advising a reboot cycle for services normally started at boot, like networking). If the user answers yes this time then it is taken off the list, if they answer no then neither of the config files (custom or new default) would have worked, but at least they can still find their old config file as (for example) /etc/X11/xorg.conf.ubuntu_6.10 (should there be a "rollback" option if the new config works, or would this just add complexity to the interface when we already know it didn't work properly?). If neither works then maybe a message should appear along the lines of "We apologise but it appears that the fix for your extra pointing device does not work in this version of Ubuntu. You may find the solution on the Ubuntu help wiki or in the Ubuntu forums. The problem lies with the file "/etc/X11/xorg.conf" which now has standard Ubuntu <insert upgraded-to-version here> content." (Knowing the file will help forum people diagnose the problem, knowing that it has been changed to a standard Ubuntu X.XX file in terms of content means they know what the user has [since a custom config file could look drastically different])

On a side note, using a GUI tool to build and install (via checkinstall) downloaded source archives would enable such custom packages to automatically rebuild themselves on dist-upgrades (as long as the souce is still in the same location) and hence fulfill part of this spec.

Here is a quick mock up showing the kind of thing I mean.

CategorySpec

PainlessUpgrade (last edited 2008-08-06 16:22:26 by localhost)