PainlessUpgrade

Revision 1 as of 2007-04-05 17:29:01

Clear message

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. And that was what we were laughing 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" functionnalities 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 keeped 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 upgrad 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 dependancies. Because the system can assume that those are the packages you really want. Such a list is already maintened 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


CategorySpec